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ABSTRACT 


NASA is examining the utility of requiring a certain degree of commonality in both flight and 
ground systems in the Constellation Program. While the benefits of commonality seem obvious 
in terms of minimizing upfront development and long-term operations and maintenance costs, 
success in real, large-scale engineering systems used to support launch operations is relatively 
unknown. A broad literature review conducted for this paper did not yield a single paper 
specifically addressing the application of commonality for ground systems at any launch site in 
the United States or abroad. This paper provides a broad overview of the ground systems, 
captures historical and current application of commonality at the launch site, and offers 
suggestions for additional research to further develop commonality approaches. 
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1 Introduction and Thesis Overview 


NASA is once again engaged in a program to develop flight and ground systems to support our 
Nation’s return to the moon and the eventual human exploration of Mars. A key component in 
the execution of the new program is the effort to minimize near-term development and long-term 
operations costs. Several approaches are currently employed to achieve these goals including 
reuse of existing flight hardware and infusing operability into the design of new and modified 
systems. NASA is also examining the utility of requiring a certain degree of commonality in 
both flight and ground systems. While the benefits of commonality seem obvious in terms of 
minimizing upfront development and long-term operations and maintenance costs, success in 
real, large-scale engineering systems used to support launch operations is relatively unknown. A 
broad literature review conducted for this paper did not yield a single paper specifically 
addressing the application of commonality for ground systems at any launch site in the United 
States or abroad. This paper provides a broad overview of the ground systems, captures 
historical and current application of commonality at the launch site, and offers suggestions for 
additional research to further develop commonality approaches. 

While the focus of space programs is traditionally the flight hardware such as the Saturn V, 
Apollo Lunar Module or Space Shuttle Orbiter, ground systems represent a non-trivial 
development and operations component of space flight programs. As far back as the German V- 
2 program, the magnitude ground systems were recognized. Dieter Huzel, a close aid to the 
inventor of the V-2, Werner von Braun, wrote in 1962: 

The full meaning and understanding of the fact that in addition to the missile itself, at 

least as much equipment is also needed to prepare it for flight... '. 

The Space Shuttle System was originally intended to support up to 50 flights per year requiring 
far fewer ground systems and less effort to operate than traditional launch systems. As the 
complexity of the flight hardware grew during design and development phases, so did the 
magnitude of the ground systems. An early concept drawing for ground processing is shown in 
Figure 1. 
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Figure 1: Early Space Shuttle Orbiter Ground Processing Concept (NASA) 

A portion of the actual ground systems used to support Orbiter horizontal processing is shown in 
Figure 2. The Orbiter’s nose and Forward Reaction Control System can be seen protruding from 
ground systems far more complex than originally envisioned by system designers. 



Figure 2: Space Shuttle Orbiter in the Orbiter Processing Facility [NASA] 

In Figure 3, Technicians are shown installing interface cables between the Shuttle Mobile 
Launch Platform and the Launch Pad. Every one of these cables provides electrical power 
and/or communications from a ground system. 
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Figure 3: Interface between Shuttle Mobile Launch Platform and the Launch Pad [NASA] 

The development and operation of ground systems at the launch site represent a substantial 
component of the overall life cycle costs of a space flight program. The relative size of the 
Constellation Program Ground Operation budget with respect to flight hardware project budgets 
is shown below in Figure 4. Ground Operations includes development of ground systems and 
the processing of flight hardware through launch. 



Figure 4: Constellation Projects Budget Comparison 
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Thesis Overview 


This paper serves as a foundation to understand past and current efforts to achieve commonality 
during the Apollo, Shuttle, Space Station and Constellation Programs at the Kennedy Space 
Center. By examining commonality in these programs, significant factors affecting the 
application of commonality can be identified for future efforts. A complete description of the 
system architecture for a space flight program includes the spacecraft, launch vehicles and 
ground systems. Current research in the application of commonality in spaceflight programs is 
focused on flight hardware systems and to some degree, project management. While many 
readers are familiar with the flight hardware configurations of the Apollo, Space Shuttle, 
International Space Station and Constellation Programs, most are not familiar with the systems 
used to support ground processing and launch. Broadly defined, ground systems includes the 
land, facilities and systems required to support pre-launch, launch operations, landing and 
recovery operations, flight crew training, missions operations and communication systems. A 
discussion regarding ground systems commonality requires an understanding of the nature of the 
work and equipment used at the launch site. Therefore, this paper includes high-level 
descriptions of the processing concepts and ground systems of the Apollo, Space Shuttle, 
International Space Station and Constellation Programs. 

Chapter 2 begins by defining the terms ‘launch site’ and ‘ground systems’ using the Object 
Process Methodology (OPM) to provide framework to describe the systems used to process and 
launch the astronaut crew and flight hardware. A historical overview of the Kennedy Space 
Center (KSC) is provided to capture how the most basic question of where to locate the launch 
site was determined for the Apollo Program. The generic Object Process Diagram is presented 
to provide solution neutral description of the launch site. The origin of each program and a 
description of the flight hardware are provided in order to establish the context required for the 
more detailed descriptions of the facilities and ground systems used at the Launch Site. 

In Chapter 3, a broad literature review is presented outlining current research into commonality. 
It includes descriptions of applications and methods used to implement commonality and project 
management challenges associated with the implementation of commonality. 

A framework for assessing commonality in ground systems is presented in Chapter 4. The 
framework addresses development and operational phases of the system. The framework 
management as well as the levels and types of commonality achieved for each program are 
presented. 

In Chapter 5, the framework presented in Chapter 4 is applied to ground systems used for 
Apollo, Shuttle, International Space Station Programs and Constellation Programs. 

The thesis concludes in Chapter 6 with a summary of key findings from the frame work analysis 
of the Apollo, Shuttle, ISS and Constellation programs and suggestions for future research. 
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2 Ground Systems Overview 


This chapter provides an overview of ground systems used to support launch operations at the 
Kennedy Space Center during the Apollo, Shuttle and International Space Station Programs and 
future ground systems planned to support the new Constellation Program. While the 
commonality concepts discussed later in this paper apply to many launch sites around the world 
today, this paper focuses on the infrastructure and ground systems at the Kennedy Space Center. 
For the remainder of the paper, the terms ‘Kennedy Space Center’ and ‘launch site’ will be used 
interchangeably. The chapter begins by describing the launch site using Object Process 
Diagrams 2 . The OPDs are intended to provide the reader with a high level understanding of the 
nature of the work at the launch site prior to describing specific ground systems used in human 
spaceflight programs at KSC. A brief description of the origins of the U.S. launch capability is 
included to provide a historical context of the decisions that led to the selection of Cape 
Canaveral and a large section of Merritt Island for the America’s primary launch site. The 
chapter concludes with high level descriptions of the ground systems used for Apollo, Shuttle, 
International Space Station and those planned for use in the Constellation Program. This chapter 
is intended to familiarize the reader with the size and complexity of systems required to process 
launch vehicles and spacecraft from the four different programs. 

2.1 Launch Site Object Process Diagrams (OPD) 

The following OPD diagrams provide a high-level solution-neutral description of the launch site 
and will be used to aid in the description of ground systems at the Kennedy Space Center and 
how they evolved to support the Apollo, Space Shuttle, ISS and Constellation Programs. The 
processes describe the nature of work performed at the launch site. The product system 
boundary between the launch site and relevant external objects is shown in the first OPD 
diagram below: 
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Figure 5: Launch Site Whole System Object Process Diagram 

At the highest level, the process ‘launching’ requires the ‘launch site’ to yield ‘launched’ Flight 
Crew, Flight Equipment, Spacecraft and Launch Vehicle. The objects and processes in the 
diagram are defined as follows: 

Objects 


• Launch Site: The land and ground systems required to enable the launch of the Crew, 
Spacecraft, Launch Vehicle and Flight Equipment 

• Flight Crew: Astronauts to be launched into space 

• Cargo: Describes flight crew equipment, equipment required to perform science 
experiments. Orbital Replacement Units for sparing or to replace malfunctioning 
equipment already on-orbit and in-space logistics items such as food, water, oxygen. 
Flight Crew Equipment (FCE) includes Extra Vehicular Activity (EVA) Suits, clothing, 
tools, laptop computers and other equipment intended to fly into space to enable the 
astronauts to perform their required tasks. 

• Spacecraft Elements: Flight hardware that is integrated and serviced on the ground, 
mated to the launch vehicle and enters earth orbit. Examples include the Apollo 
Command/Service Module, Space Shuttle Orbiter and components of the International 
Space Station. The origin of the flight hardware may be a manufacturer or refurbishment 
facility. 
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• Launch Vehicle Elements: Flight hardware that when integrated and serviced on the 
ground comprise the ‘rocket’. Examples include the Saturn V, Space Shuttle and the 
Constellation Ares-I Crew Launch Vehicle. 

• Logistical Items: Includes all goods and materials required to perform launching. 
Examples include propellants, gaseous nitrogen, helium, electricity, water, office 
supplies, spare parts, gasoline, etc. Traditionally, logistics and other institutional support 
organizations manage requirements for commodities. 

• Range: Primary function is to insure the safety of workers and public in the area 
surrounding the launch pad. The Range is capable of initiating the destruction of the 
launch vehicle via encrypted radio command from the ground. Typically located at or 
near a launch head (such as the Kennedy Space Center/Cape Canaveral Air Force Station 
(CCAFS). Consists of owned or leased facilities on downrange sites. Controls access to 
all surrounding land, sea, and air space within the reach of any launch vehicle extending 
along the launch azimuth. 

• Communications and Tracking (C&T): Radio Frequency communication such as S-Band, 
UHF, and Ku-Band. Data, Audio, and Video are transmitted to and from the spacecraft, 
launch vehicle, and ground. 

• Weather: The state of the atmosphere at a given time and place, with respect to variables 
such as temperature, moisture, wind velocity, and barometric pressure 3 . Weather far 
from the actual launch site is also a key consideration for the Space Shuttle Program. 
Space Shuttle Program requires acceptable landing weather for at least one trans- Atlantic 
abort sites prior to launch. Also includes sea states (wave height, period, ocean 
temperature, etc.). Sea-states affect the ability to rescue the crew in the event of an abort 
during ascent. 

• Crew, Flight Equipment, Spacecraft, Launch Vehicle -> Launched: The primary 
beneficiary of the process ‘launching’ is changing the state of the aggregate of flight, 
crew flight equipment and spacecraft elements and launch vehicle elements to 
‘Launched’. 

Processes 


• Launching: The process that performs all ground operations required to launch the flight 
crew, flight equipment, spacecraft elements and launch vehicle elements. 
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The first level OPDs are shown below 



Figure 6: Launch Site Level 1 Object Process Diagram (1/3) 



Figure 7: Launch Site Level 1 Object Process Diagram (2/3) 
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Weather, Workforce, Land and Waterways, and Logistics Items objects affect or are required by 
all processes. In order to simplify the diagram, sample relationships between these objects and 
processes are shown in the third OPD. Additionally, there are a multitude of ‘Institutional’ 
processes that are required to operate and maintain a launch site. They include maintenance of 
the entire infrastructure (buildings, roads, grounds, etc.), personnel management systems, 
weather forecasting and reporting, trash removal, etc. These objects and processes are shown for 
completeness. Institutional processing and related objects within institutional processing will not 
be addressed in this document. This is not to imply institutional objects and processes are not 
important. The institutional capabilities of a launch site are often significant factors in 
determining where to process and launch flight hardware for the next program due to 
replacement costs for developing a new site. 




Figure 8: Launch Site Level 1 Object Process Diagram (3/3) 


The objects and processes internal to ‘launch site’ and ‘launching’ in the second level OPD 
diagram are defined as follows: 

Internal Launch Site Objects 

The description of launch site objects begins by defining a generic Ground Systems object which 
will be the focus of the commonality assessment in Chapter 5. The definition applies to ground 
systems supporting launch vehicle and spacecraft processing, integrated operations and launch 
operations. 
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Ground Systems typically consists of three internal objects: Facilities, Ground Support 
Equipment (GSE) and Support Equipment (SE). The aggregation of ground systems is shown in 
the Figure below. 



Figure 9: Ground Systems Aggregation 

Over the years, the meaning of the term ‘Ground Support Equipment’ evolved to include 
only systems that directly interfaces physically with the flight hardware such as handling 
equipment, servicing equipment, test equipment, plugs, covers, etc. The term ‘Support 
Equipment’ refers to all other hardware at the launch site that does not interface directly to 
the flight hardware. GSE is often developed and provided by the flight hardware 
manufacturer while SE is typically developed by the Ground Operations project at KSC. 
Definitions and examples of all three objects internal to ground systems are described below: 

o Facilities: Buildings Structure (walls, floor, roof) and Facility System Equipment 
(FSE). FSE are integral to the building including overhead bridge cranes, 
airlocks, heating, ventilation and air conditioning, conditioned power, service 
interfaces to gaseous helium, nitrogen and other fluids and gases, fire protection, 
environmental monitoring, closed circuit TV, vacuum cleaning systems, etc. 

o Ground Support Equipment: Examples of GSE include special servicing 
equipment to test and check-out spacecraft subsystems such as avionics, 
environmental and control and life support, propulsion, electrical power, etc. 
Mechanical examples include lifting slings, certain types of transporters, special 
handling equipment, interior access platforms, window covers, etc. 
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o Support Equipment: Includes command and control systems, work stands, air 
bearing pallets, mobile environmental control systems, pumps, etc. 

• Offline Spacecraft Ground Systems: Buildings and Facility System Equipment (FSE) 
that support Spacecraft Element and Integrated Spacecraft processing. Offline Spacecraft 
Facilities are usually required maintain at least 100K Clean Work Areas (CWA). 
Spacecraft GSE and SE may move with the spacecraft into integrated operations and 
launch operations processes. 

Note: ‘ 100K’ refers to particulate count per cubic foot. Other forms of contamination are also 
controlled including volatile hydrocarbons, non-volatile residue, etc. Clean Work Areas also 
require air positive pressure, controlled temperature and humidity and appropriate monitoring 
equipment. 

• Prepared Spacecraft Elements: Flight hardware elements received from the manufacturer 
or refurbishment facility that are processed in offline processing facilities. All special 
shipping restraints and fixtures are removed. Element subsystems are serviced and tested 
as required prior to Integrated Spacecraft Processing. 

• Offline Launch Vehicle Ground Systems: Buildings and Facility System Equipment 
(FSE) that support Launch Vehicle Element processing. Works areas are required to be 
Foreign Object Debris free. However, they are not typically required to meet the more 
CWA requirements used for spacecraft processing. Launch vehicle GSE and SE may 
move with the spacecraft into integrated operations and launch operations processes. 

Note: Damage to, or malfunction of, a launch vehicle or payload caused by any foreign object(s) 
that are alien to flight systems. FOD may cause material damage or it may make the system or 
equipment inoperable, unsafe or less efficient. FOD can consist of staples, paper clips, paper, 
particles generated from operations such as sanding, drilling and welding, liquids and chemicals, 
food, clothing, lost screws, nuts and washers, tools such as wrenches and screwdrivers, jewelry 
such as earrings, bracelets, watches and rings, eye glasses, plastic and rubber, tape, string, tie 
wraps, safety wire. [NASA] 

• Prepared Launch Vehicle Elements: Flight hardware elements received from the 
manufacturer or refurbishment facility that are processed in offline processing facilities. 
All special shipping restraints and fixtures are removed. Element subsystems are 
serviced and tested as required prior to Integrated Launch Vehicle/Spacecraft Processing. 

• Prepared Cargo: Equipment removed from shipping containers and inspected for 
shipping damage. Usually involves minimal check-out at the launch site. Each item is 
specially packed at the launch site and placed into containers unique to spacecraft cargo 
areas. Prepared Cargo may be stowed in spacecraft processing facilities, integrated 
operations facilities or while at launch operations facilities. The more time sensitive the 
cargo, the more likely it will be stowed later in the flow and sometimes just prior to 
launch. Examples of time sensitive cargo included food and live biological experiments. 

• Integrated Spacecraft: Mated flight hardware elements that comprise the spacecraft. 


- 20 - 


• Integrated Operations Ground Systems: Typically very large buildings and building 
systems that support stacking of the launch vehicle and mating of the spacecraft to launch 
vehicle. Examples of GSE and SE include handling equipment such as lifting slings, 
measurement and leveling and alignment systems, special launch vehicle mating 
equipment, interim protective, enclosures, tensioning equipment, etc. Integrated 
Operations GSE and SE may move with the spacecraft into integrated operations and 
launch operations processes. For KSC, the Shuttle Mobile Launch Platform is an 
example of GSE that supports stacking operations in the VAB and Launch Operations on 
the Pad. 

• Integrated Spacecraft-Launch Vehicle: Commonly referred to as the ‘stack’. Consists of 
all mated, flight hardware elements. 

• Launch Operations Ground Systems: Buildings, structures GSE and SE supporting the 
final check-out and launch of the Integrated Spacecraft-Launch Vehicle at the Launch 
Pad. Provides access to flight hardware and limited weather protection (primarily 
lightning). Includes fluid and gas systems used to service and fuel flight hardware, 
special test and measurement systems, command and control system components, sound 
suppression systems, etc. 

• Landing and Recovery Operations Ground Systems: Facilities, GSE and SE supporting 
recovery of spacecraft and launch vehicle elements such as Shuttle SRBs and Shuttle 
Orbiter. Examples include the Shuttle Landing Facility, and recovery vessels supporting 
future recovery operations of the Constellation CEV Crew Module. 

• Landed Flight Crew: Astronauts returned from on orbit operations. 

• Recovered Launch Vehicle Elements: Elements of the launch vehicle recovered 
following launch for re-use or inspections such as the Shuttle SRBs. 

• Recovered Spacecraft Elements: Elements of the Spacecraft recovered following landing 
such as the Space Shuttle Orbiter and Constellation Crew Exploration Vehicle Crew 
Module. Recovery operations may occur on land or water. 

• Logistics Systems: Buildings and building systems used to process store and distribute 
flight hardware (ORU level only), ground hardware, and commodities at the launch site. 
SE includes inventory tracking and control systems, systems, transportation systems 
(tugs, tractors and specialized transporters). 

• Processed Logistical Items: Commodities, goods and materials checked in through 
launch site shipping and receiving procedures. Components repaired in on-site depot 
level maintenance facilities. 
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• Institutional Support Facilities: Buildings and building systems for office and 
administrative areas, medical, fire and rescue, maintenance, security, on-site labs, public 
affairs, etc. 

• Land and Waterways: Property owned and managed by launch site. 

• Workforce: Personnel required for launching. Personnel may or may not be located at 
the launch site. Consists of government and contractor workers performing the entire 
range of required tasks from executing launch countdown procedures in the launch 
control center to removing the trash. 

• Prepared Flight Crew: Suited astronauts following final medical checks ready to board 
spacecraft. 

Internal Launch Site Processes 

• Offline Cargo Processing: In most cases, this involves simply removing hardware from 
the shipping container, inspecting it, and repacking into containers unique to spacecraft 
cargo areas. In some cases, experiment hardware arrives at the launch site in multiple 
elements and must be assembled and tested prior to stowage in the spacecraft. 

• Offline Launch Vehicle Element Processing: Typical processing activities include 
removal from shipping container, post shipping inspections, placing flight hardware 
element into work stands, connecting various GSE such as special test equipment, power 
conditioners, environmental control systems, air monitoring systems and executing test 
procedures required at this phase of the processing flow. Element interfaces are tested 
and checked-out. 

• Offline Spacecraft Element Processing: Similar to Launch Vehicle Element Processing. 
Typical processing activities include removal from shipping container, post shipping 
inspections, placing flight hardware element into work stands, connecting various GSE 
such as special test equipment, power conditioners, environmental control systems, air 
monitoring systems and executing test procedures required at this phase of the processing 
flow. When the element is to be mated to another flight element later in the processing 
flow or to an element already on orbit, flight emulators are sometimes used to test 
element interfaces. In some cases, final assembly of a flight vehicle element may occur 
in this process such as installation of thermal blankets, installing access covers, etc. The 
Flight Crew will perform support walk-downs and inspections of the spacecraft to ensure 
the actual flight hardware configuration is consistent with simulators and procedures used 
during extensive training exercises. 

• Integrated Spacecraft Processing: Prepared spacecraft elements are mated to form the 
complete spacecraft. Interfaces between the spacecraft elements are tested and verified. 
Additional integrated check-out of spacecraft subsystems may be performed. Final 
spacecraft closeouts are performed and any necessary purges are established to provide 
environmental control with spacecraft. The integrated spacecraft is enclosed in a 
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transportation container and transported to the integrated operations facility. The Flight 
Crew may also perform support walk-downs and inspections of the spacecraft during this 
phase to ensure the actual flight hardware configuration is consistent with simulators and 
procedures used during training exercises. 

• Flight Crew Preparing: A few months prior to launch, the flight crew will participate in 
emergency egress training at the launch pad and Terminal Countdown Demonstrations 
Tests. About three weeks prior to the flight, the astronauts are placed under limited 
medical quarantine to prevent exposure to communicable diseases. Only authorized 
personnel are allowed to interact with the astronauts. The quarantine continues following 
their arrival at the launch site about 3-4 days prior to lift off. Shuttle Astronauts typically 
arrive at the launch site about 3-4 days prior to launch. While at the launch site, they 
receive final briefings on the state of the flight hardware, weather and any updates to 
mission plans. Shuttle pilots and co-pilots also practice approach and landing tests at the 
Shuttle Landing Facility using the Shuttle Training Aircraft. On the day of launch, the 
astronaut crews are checked-out one more time by medical personnel, suited up and 
transferred to launch pad to board the orbiter. During Apollo, astronaut crews arrived at 
the launch site as much as 90 days prior to launch participated in mission simulations. A 
Flight Crew Training Building with Lunar Module and Command Module Simulators 
was located at KSC during Apollo. It was used extensively in the months prior to launch. 
A terrestrial version of the rover along with a simulated lunar bolder field was used to 
practice lunar EVAs. 

• Integrated Spacecraft/Launch Vehicle Operations Processing: Launch Vehicle Elements 
are transported to the Integrated Operations Facility. Transportation GSE is removed and 
lifting GSE is attached to allow the flight hardware element to be hoisted and attached to 
the Mobile Launch Platform (MLP). This continues with additional launch vehicle 
elements until the vehicle assembly is complete. This process is sometimes referred to as 
stacking. Once the launch vehicle is stacked, the spacecraft is transported to integrated 
operations facility and the transportation container is removed. Lifting GSE is attached 
to the spacecraft and then it is hoisted and mated with the Launch Vehicle. Both vehicles 
are powered up and a series of integrated tests are performed to verify critical interfaces 
between the launch vehicle and spacecraft. SE is sometimes attached to the launch 
vehicle to measure induced loads during transportation. The integrated spacecraft/launch 
vehicle is then transported to the launch pad. 

• Launch Operating: Once the integrated spacecrafit/launch/MLP vehicle arrives at the 
launch pad, the MLP is mated to the launch pad. Fluid, gas and electrical interfaces 
between the launch pad and the MLP are tested and verified. Prior to entering launch 
countdown, an additional spacecraft and launch vehicle servicing may be performed such 
as hypergolic fuel and oxidizer loading for reaction control systems; commodity loading; 
late stowage of time-sensitive science experiments and EVA hardware. Launch 
countdown begins and final preparations are made to the launch vehicle and spacecraft 
including arming of pyrotechnic devices; loading of cryogenic propellants; verification of 
command and data links; ingress of the flight crew; voice communication test, etc. The 
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countdown terminates with the launch of the spacecraft and crew. Post launch 
inspections are conducted of ground systems and preparations begin for the next launch. 

• Landing and Recovery Processing: Includes processes required to support recovery 
operations launch vehicle elements such as the Shuttle Solid Rocket Boosters; Landing 
Operations for Shuttle Orbiter; water landing and recovery operations for the 
Constellation Orion Crew Module. Launch Abort contingency operations are also 
included in this process. 

• Logistical Items Processing: Includes logistics engineering, inventory management, 
government property management, kiting, shipping, receiving and warehousing, 
transportation and depot level maintenance. 

• Institutional Processing: Includes administrative and support functions common to very 
large facilities such as those found on military bases and large manufacturing facilities. 
Administrative functions include personnel management, human resources development, 
financial management, procurement, etc. Support functions include: security; fire and 
rescue; operations and maintenance of the infrastructure (roads, railways, power 
distribution systems, etc.) and facilities. 

2.2 Cape Canaveral 

Near the end of the Second World War, many of the German Scientists and Engineers including 
Werner von Braun, who was responsible for the development of the V-2 missile, continued their 
work for the American military first in Texas in 1946, then the White Sands Proving Grounds in 
New Mexico. Cape Canaveral was actually selected by the military to test missile missiles in 
1947 primarily due to its location on the south east coast of the United States and the ability to 
launch over unpopulated regions. Cape Canaveral is located approximately 28.5 degrees north 
latitude allowing for launch over water at azimuths of 37 degrees and 114 degrees. 


- 24 - 



90W qo 30 0 30 60 


Figure 10: Typical Launch Sector for Launches from the Eastern Range 4 

Note: It is possible to launch into earth orbits from Cape Canaveral at higher or lower azimuths 
by performing a ‘dog leg’ maneuver during ascent to avoid populated areas. However, this 
maneuver consumes additional propellants and lowers a launch vehicle’s overall payload to orbit 
capability significantly. 

In the late 1940s, Cape Canaveral was sparsely populated whose most notable feature was the 
large light house erected in 1847. Launch pads were located within 500 yards of the coast 
allowing largely experimental rockets to fly over water away from the surrounding communities. 
In 1950, the Army moved the development team lead by Werner Von Braun to the Redstone 
Arsenal in northern Alabama. The rocket test program moved to Cape Canaveral, the hub of the 
newly created Atlantic Missile Range. Early launches included the Bumper 8 and a V-2 with 
WAC Corporal upper stage on July 23, 1950. Throughout the 1950’s, hundreds of 
intercontinental ballistic missile including the Army’s Jupiter and Thor and the Air Force’s Atlas 
Delta and Titan programs were tested and launched from Cape Canaveral 5 . 

With the launch of Sputnik on October 4, 1957 the ‘Space Race’ between the United States and 
the Soviet Union began. In response, military leaders selected the Navy’s Vanguard missile as 
the primary vehicle to launch America’s first satellite. Von Braun’s Redstone Program under the 
Army Ballistic Missile Agency (ABMA) was also given authority to proceed as a back-up to 
Vanguard. Following the famous Vanguard failure broadcast live on American Television, 
America’s first satellite, Explorer I was finally launched by the Army’s Redstone missile from 
Cape Canaveral on January 31, 1958 6 . 
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Later in July, President Eisenhower signed the Space Act of 1958 establishing the National and 
Aeronautics and Space Administration to lead America’s civilian space effort. Von Braun’s 
work at the Redstone Arsenal and a number of other organizations involved in related research 
including the Jet Propulsion Laboratory in California was transferred to NASA as part of an 
overall effort to focus America’s space effort on civilian applications in 1959 7 . However, as 
Liparito and Butler point out, commonality of technology between military and civilian would 
require some level of cooperation 8 . 

Given the substantial infrastructure already in place to support military missile test programs, 
Cape Canaveral was the obvious choice to launch the Mercury and Gemini missions. Between 
May 1961 and 1966, twenty-six astronauts were launched from Mercury-Redstone, Mercury- 
Atlas and Titan-Gemini launch complexes on Cape Canaveral. 


2.3 Apollo 

The development of the Saturn class launch vehicles began as a series of studies in April 1957 
under the ABMA as the ‘Super-Jupiter’ and was directed by von Broun’s team in Huntsville, 

AL. The original intent was to greatly increase the capability to existing launch vehicles to orbit 
large communications satellites, space probes and weather satellites. Keep in mind that the US 
did not yet successfully orbit a satellite when the Saturn program was initiated. By 1958, 
through the cooperation of the newly formed Advanced Research Projects Agency (ARP A) and 
the ABMA, the Juno-V studies were formally funded to determine how to produce a launch 
vehicle with the capability of 1,500,000 lb. thrust. The development team made substantial 
progress early and ARPA approved the development of flight hardware leading to plans for three 
flight tests for a launch vehicle with a cluster of 8 Redstone class engines. 

The national uncertainty generated by the launch of Sputnik generated numerous studies and 
committees all attempting to establish a plan for future American launch vehicles. The “Rosen 
Report 9 ’ submitted to President Eisenhower in January 1959 called for the development three 
classes of launch vehicles: Atlas/Atlas Centaur; Juno V; and a Nova class launch vehicle with 6 
million pounds of thrust at lift-off. The report stated that the Nova class launch vehicle would 
support manned flights to the lunar surface. Later in the year, the Department of Defense 
renamed the Juno V Project the Saturn Project. Just a few short months later, the Saturn Project 
was nearly cancelled by the Department of Defense by those who felt the cost of the large 
booster was not justified to simply loft a large communications satellite. In June, a report titled 
Project Horizon included plans for a 12 person military base on the lunar surface by 1965 
requiring 64 Saturn launches per year to sustain the crew 10 . Negotiations between personnel 
from NASA, Army and the Air Force agreed to continue the Saturn program under the 
provisions that it would be transferred to the ABMA and NASA with its own additional funding. 

Development of the new class of launch vehicles began with the Redstone derived Saturn I. In 
1958, Kurt Debus, a member of von Braun’s original V-2 development team, traveled to Cape 
Canaveral to discuss the requirements for a new launch complex to support the Saturn I test 
Program. A new site just north of Titan Launch Complex 34 was selected after factoring in the 
much wider blast safety zones around the pad required by the much larger Saturn 1 1 1 . Between 
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1961 and 1968, 4 Satum-I and 3 Satum-IBs were launched from Complex 34. It was also the 
site of tragic Apollo 1 fire that claimed the lives of Virgil Grissom, Edward White and Roger 
Chaffee in 1967. Following a 21 month stand-down to investigate and implement dozens of 
technical and procedural issues, the first crewed Apollo mission was launched from Complex 34 
on October 11, 1968 12 . 

With the Satum-I test program was well underway, additional engineering studies continued into 
1960 with the development of the Saturn V, The Saturn V was viewed necessary step in the 
development of the Nova class launch vehicle still viewed as the primary means to achieve a 
human lunar landing. NASA planners called for an Apollo manned orbiting lab and circumlunar 
flights between 1968 and 1970. Lunar landings were assumed to occur sometime after 1970 13 . 
The development of the spacecraft Apollo program was actually initiated by the President 
Eisenhower in 1 960 as a follow-up to the Mercury Program. The original intent of the program 
was to develop a three man spacecraft that could carry astronauts to low earth orbit and 
eventually to perform a circumlunar missions 14 . 

Following the presidential election in 1960, numerous briefings were provided to President John 
F. Kennedy and his staff regarding the progress of both the civilian and military space programs. 
After only 4 months after taking office and with the threat of the Soviet Union’s perceived 
technological superiority casting a cloud of fear over the nation, newly elected President John F. 
Kennedy gave his famous speech to a joint session of congress in 1961 : 

“...I believe that this nation should commit itself to achieving the goal, before this decade is 
out, of landing a man on the moon and returning him safely to the earth 15 

It was this speech that established the Apollo Program as a national priority, provided the 
impetuous for bipartisan support for funding and set the deadline for the first human mission to 
the surface of the moon to be completed by 1969. 

By May of 1961 , the Saturn V and Apollo spacecraft were still just concepts on paper and the 
trade studies for the ground systems required to support process and launch were just starting. A 
variety of launch vehicle configurations continued to be studied well in the 1962. In July, NASA 
settled on the Saturn V over Nova following the decision to use the lunar-orbit-rendezvous over 
other methods for reaching the lunar surface and returning to earth. 

Studies were intiated to answer the most basic question: Where to locate Apollo-Satum V 
Launch Complex? While Cape Canaveral seemed the obvious location to build the massive 
infrastructure required to support the moon program, there were concerns about larger blast 
radius and the launch danger areas required for the Saturn V. Additionally, by the early 1960’s, 
the DOD’s missile test program had already used much of the space on Cape Canaveral. 
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Figure 11: Aerial view Cape Canaveral Air Force Station in the early 1960’s [NASA) 

Planning for the infrastructure and systems at the launch site was led by Kurt Debus, the director 
of the Launch Operations Directorate (LOD). At the time, the LOD still reported directly to von 
Braun’s team at the Marshal Space Flight Center in Huntsville, AL. In 1961, a House 
Committee “Report on Cape Canaveral Inspection” observed that available space for new launch 
complexes was limited. During this period, the DOD continued to be heavily involved in the 
lunar program. Numerous agreements existed between NASA and DOD since the formation of 
NASA that included the use of the range at Cape Canaveral 16 . While overall operations of the 
spaceflight program were clearly a NASA responsibility, all launch facilities and systems used to 
date were located on Air Force property. Additionally, the Air Force owned all Range assets 
including sophisticated tracking and communication equipment on-site and further down range 
as far as Ascension Island in the South Atlantic. 

A joint NASA- Air Force study was initiated by Debus and Air Force General Leighton Davis to 
determine where to launch the Saturn V. Many of the factors driving the decision as to where to 
locate the new Launch Complex were safety related. The Joint NASA-Air Force Hazards 
Analysis Board examined the effects of Blast, Noise, fire, fragmentation, radiation and toxicity 17 . 
At the time, both Saturn and Nova class launch vehicles were still under consideration. 
Additionally, NASA and the Atomic Energy Committee were pursuing nuclear powered upper 
stages for space applications 18 . Therefore, safety zones around the launch pad were established 
for both vehicles as well as potential nuclear powered upper stages. 

In early 1960s, an off-shore launch complex for both Saturn and Nova programs was studied that 
intended to leverage off the same technology used in off-shore oil rigs. The approach allowed 
the launch complexes to be located far away from population centers eliminating the public 
safety hazards. Additionally, due to the size of the Saturn and Nova first stages, water transport 
was the only method available to ship the stages from the manufacturing facility to the launch 
site 19 . The committee studied seven land bases sites and one off shore site: Cape Canaveral 
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(would require the acquisition of additional land adjacent to Cape Canaveral), Offshore from 
Cape Canaveral; Mayaguana Island in the Bahamas; Cumberland Island, Georgia area near 
Brownsville, Texas; White Sands Missiles Range in New Mexico; Christmas Island in the South 
Pacific; and South Point on the island of Hawaii. The island sites in the Bahamas, South Pacific 
and Hawaii were rejected on the basis of expected high costs of development and operations. 
Since White Sands was located in the middle of New Mexico, booster transportation via sea 
thought to be required via waterways was not possible. Vehicles launch from the Texas site 
would fly over large population centers and thus was rejected as well. While Cumberland Island, 
Georgia met all technical criteria, expensive new tracking equipment was going to have to be 
built downrange. 



Figure 12: Water Transportation Route for Saturn Boosters 20 


Ultimately, Cape Canaveral was selected over Cumberland Island largely due to the cost of 
additional range assets 21 . Between 1962 and 1964, four separate tracts of land on the northern 
half of Merritt Island to the west and north of Cape Canaveral were purchased by the Army 
Corps of Engineers 22 and NASA 23 . The land, facilities and ground systems built on it to support 
the lunar program would later become the Launch Operations Center led by Center Director Kurt 
Debus, reporting directly to NASA Headquarters in Washington D.C. and independent of the 
Marshal Space Flight Center. In November, 1963 it was renamed the John F. Kennedy Space 
Center in honor of the slain president. 

It is important to point out that the Air Force retained ownership of all of the original launch 
complexes, range assets and land on Cape Canaveral. In 1964, the Air Force renamed the 
Atlantic Missile Range the Cape Canaveral Air Force Station (CCAFS). To be precise, the 
‘Cape’ is the CCAFS. 
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Figure 13: KSC (white) and neighboring Cape Canaveral Air Force Station (Green) 

Flight Hardware 

Werner von Braun “ preached and practiced that rocket and launch pad must be mated on the 
drawing board, if they were to be compatible at the launching 24 ' 1 ' . The flight hardware 
configurations are the primary drivers for requirements for facilities and ground systems. A brief 
description of the Saturn V Launch vehicle, Apollo Spacecraft, and high-level ground concept of 
operations is described in order to provide context for more detailed descriptions of facilities and 
ground systems developed for Apollo Program. 

The Saturn V launch vehicle consists of three stages and the Instrument Unit. Additional details 
included size, weight, thrust and propellant types are shown in the following drawings. 
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Figure 14: Saturn V Launch Vehicle [NASA] 

The Saturn V is the largest launch vehicle built to date both in terms physical size and payload 
lift capability. 

The Apollo spacecraft consisted of five major assemblies: the Command Module (CM), the 
Service Module (SM), the Lunar Module (LM), the Spacecraft/Lunar Module Adapter (SLA), 
and the Launch Escape System (LES). The CM housed the three person astronaut crew in during 
ascent, operations in low earth orbit, lunar orbit and re-entry. The Service Module contained the 
hypergolic propulsion systems used for the lunar orbit insertion, trans-earth injection, 
commodities such as oxygen for breathing air and the fuel cells, and SM hypergolic reaction 
control system. 

Note: Hypergolic propulsion systems are very reliable and relatively simple compared to other 
systems that require igniters. However, the propellants used in hypergolic systems are extremely 
toxic and require special handling procedures and facilities. 

The Launch Escape System provided the means to separate the CM from the remainder of the 
Apollo-Satum stack in the event of catastrophic emergency on the launch pad or during the 
atmospheric phase of ascent. The LES was jettisoned about three minutes after liftoff at an 
altitude of 60 miles. The Space Craft Launch Adapter protected the Lunar Module during ascent 
and provided structural support between the CM/SM and Saturn V SIVB stage. The mated 
CM/SM (or CSM) was just over 36 feet tall and had a total dry weight of about 66.9 thousand 
pounds. 
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Figure 15: Command/Service Module [NASA] 

The Lunar Module consists of two elements including the Descent Stage and Ascent Stage and 
was 22 feet tall by 3 1 feet wide. The Ascent Stage and Descent stage were mated together with 4 
explosive bolts and had a combined dry weight of about 32 thousand pounds. The Descent 
Stage consists of a single engine hypergolic propulsion system, landing gear and modularized 
equipment bay used to store science equipment for experiments to be conducted on the lunar 
surface. The Descent Stage was also used as a launch platform for the Ascent Stage following 
lunar surface operations lasting on 1 -3 days. The Ascent Stage was an irregularly shaped 
element approximately 9 feet high and 13 by 14 feet and had a total habitable volume of 235 
cubic feet for an astronaut crew of two. Subsystems within the Ascent Stage include the reaction 
control system, three antennas systems, environmental control systems, avionics and the docking 
systems. 
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Figure 16: Lunar Module [NASA] 

In addition to the launch vehicle and spacecraft elements, lunar rovers and a variety of scientific 
equipment were also processed stowed for flight on the Lunar Module Descent Stage at the 
Kennedy Space Center prior to launch. Examples of the scientific experiments include the 
Passive Lunar Seismic Experiment, Medium-Energy Solar Wind experiment, Active Lunar 
Seismic Experiment, Heat Flow Experiment and the Laser Ranging Retroreflector. The 
equipment used for these experiments contained in the Apollo Lunar Surface Experiments 
Package (ALSEP) powered by a radioisotope thermoelectric generator (RTG) 25 . 

Ground Operations Concept 

Numerous trade studies were conducted to determine the best ground operation concept for 
processing the Apollo spacecraft and Saturn V launch vehicle. Significant factors driving the 
trades were the physical size of the launch vehicle and spacecraft elements, the desired launch 
rate and the amount of on-board propellants that contributed to large safety zones required 
around the launch pads. As many as 100 Saturn flights per year were considered as late as 1960. 
The existing approach for erecting the launch vehicle on the pad would not support the projected 
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launch rate. Building additional pads required to suppor the launch rate was ruled out due to 
construction, operations, and maintenance costs. Ultimately, the ‘mobile launch’ concept was 
chosen for the Saturn V. The primary architecture difference between the mobile launch concept 
and existing ground operations concepts at the time was where to stack the launch vehicle and 
spacecraft. Through out the 1950s and early 1960s, elements of all US launch vehicles were 
transported directly to the launch pad to be stacked. Integration with the spacecraft also took 
place at the launch pad. The mobile launch concept called for the construction of a very large 
Saturn integration building where launch vehicle elements would be processed and integrated far 
enough away from the overpressure zones around the pad. Spacecraft processing would occur 
near the integration building. The spacecraft would be mated with the launch vehicle inside the 
Saturn Integration Building. The integrated stack consisting of both the Saturn and Apollo 
Spacecraft would then be transported to the Pad for final checkout and launch. There were 
several advantages to this concept noted in the trade studies at the time: minimize loss to 
infrastructure and adjacent launch vehicles on near by pads, environmental protection again the 
salt air environment near the ocean, and hurricane protection. 26 Key elements of the mobile 
launch complex such as the VAB, Mobile Launcher and Crawler Transporter are shown in 
Figures 17 and 18. 



Figure 17: Cut-away View of the VAB [NASA] 
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Figure 18: Apollo Launch Complex 39 [NASA] 


Test and check-out flow of the Apollo-Satum Vehicle consisted of over 450 tests. Operational 
procedures conducted for Apollo 4 included were divided into nine categories: electrical 
networks (90); measuring, fire detection, etc. (49); telemetry (27); RF and tracking (21); 
gyroscopes, navigation, control, and ground operations computers (86); mechanical and 
propulsion (146); combined systems (9); launch support equipment (13); and space vehicle 
(15) 27 . The check-out procedure is shown below Figure 19. 



Figure 19: Apollo Test and Check-out Flow [NASA] 
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Apollo Ground Systems 

The Kennedy Space Center can be roughly divided into two major areas: the ‘Industrial Area’ 
and Launch Complex 39. For Apollo, a majority of spacecraft processing occurred in the 
Industrial Area. Many of the institution support facilities including large office buildings were 
also located in the Industrial Area. Launch vehicle processing and launch operations occurred at 
Launch Complex 39. A map identifying the two areas is shown below along with the blast radii 
around the Saturn V launch pads actually built (LC-39 Pad A and B) and two proposed Saturn V 
launch pads (LC-39 C and D). 



LC-39 Pad C 
(Proposed) 


LC-39 Pad B 


LC-39 Pad A 


Figure 20: Safety Zones around LC-39 Complex 39 Pads A-D (1972) [NASA] 

Launch Complex 39 C and D were sited to support nuclear payloads and higher Saturn V launch 
rates proposed during the early 1 960s and were never built following the decision to proceed 
with the Space Shuttle Program in 1972. 

As discussed previously, the existing ground systems used to launch the Saturn 1 and 1 B launch 
vehicles could not readily accommodate the launch vehicles and spacecraft planned for the lunar 
landings. Entirely new ground systems as well as a number of new institutional support facilities 
were developed on lands to the north and west of Cape Canaveral to process and launch the 
Saturn V and Apollo spacecraft. The more significant ground systems support facilities 
developed for Apollo are described below. 

Offline Spacecraft Ground Systems 

The Apollo Command Module, Service Module, Lunar Module Ascent Stage and Lunar Module 
Descent Stage arrived at the CCAFS skidstrip (runway) via separate flights on-board the 
Pregnant Guppy, a modified Boeing 377 Stratocruiser. Each spacecraft element was transported 
to the Operations and Checkout (O&C) building for offline spacecraft processing. Initially, the 
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Apollo spacecraft were planned to arrive at KSC in a flight ready condition and very little testing 
was planned at KSC. However, as spacecraft development fell behind schedule, spacecraft were 
shipped to KSC with open work from the manufacturing facility. Unplanned testing had to be 
conducted at KSC requiring far more ground systems than originally planned. Significant tests 
performed on the spacecraft during offline operations included the following: Altitude chamber 
testing in for CSM and Lunar Module Ascent Stage; CSM/LM docking tests; Several simulated 
manned altitude runs were accomplished with the prime and back up crews in the Command 
Module and Lunar Module Ascent Stage; Communication System Tests; and Fuel Cell 
installation and G&NC Test. Offline processing flows for the CSM and Lunar Module are 
shown below. 



Figure 21: Apollo CSM Offline Spacecraft Processing [NASA] 
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Figure 22: Apollo LM Offline Spacecraft Processing [NASA] 

The primary offline spacecraft processing facility was the Operations and Check-out Building. 
The building included administrative and engineering office area, living quarters for the 
astronauts, a high-bay area with two altitude chambers and an overhead bridge crane. Other 
facilities built to support offline spacecraft processing include the Hypergolic Test Building, 
Weight and Balance Building, Cryogenic Test Building and Environmental Control Systems 
Building. 
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Figure 23: LM Processing in the O&C High Bay [NASA] 


Ground Support Equipment for the Apollo spacecraft included hundreds of items ranging from 
simple widow covers to complex GN&C check-out systems. Examples of GSE for the CSM and 
Lunar Module include Fuel Cell and Cryogenic Storage Subsystem Heater and Power Supply; 
Pyrotechnics Initiator Substitute Units; Antenna Checkout Set; Fuel and Oxidizer Transfer 
Conditioning Units, Lunar Module Rendezvous Radar Test Equipment and Water Glycol 
Servicing Units 28 . The command and control system used for off-line spacecraft processing was 
the Automate Check-out Equipment (ACE). 

Offline Launch Vehicle Ground Systems 

Launch vehicle elements arrived via the barge and the Turning Basin located near the Vehicle 
Assembly Building and was transported into the VAB Low Bay. Offline check-out of the S-IC, 
S-II and S-IVB occurred in the VAB Low Bays and transfer aisle. Numerous types of GSE were 
used to check-out avionics, fluid systems, electrical power systems, etc. 

Integrated Operations Ground Systems 

VAB: The VAB was a key element of the mobile launch concept and used to stack and integrate 
the Saturn V and Apollo Spacecraft. At the time of construction, the VAB was the largest 
building in the world by volume. Characteristics of the VAB are as follows: 

• Area: VAB covers 8 acres 

• Height: 525 ft 

• Length: 158 meters 
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• Width: 518 ft wide 

• Volume: 129,428,000 cubic feet 

• Steel: 98,590 tons 

• Concrete: 65,000 cubic yards 

• Piling: 4,225 open-end steel pipe piles driven 160 ft into bedrock. 

• Air Conditioning: 10,000 tons with 125 ventilators. 

• Lifting Devices: 71 cranes including two 250 ton) bridge cranes 

• Four High Bay doors 456 ft. high 29 


• Launch Control Center (LCC): The LCC contained four firing rooms (only 3 were equipped) 
to house the 450+ member Saturn launch team and the command and control system. The 
command and control system was based on RCA 1 1 0A computers to support 400 consoles. 
Computers were housed in the LCC and in the Mobile Launcher. 

• Mobile Launcher (ML): The ML was a very large steel structure consisting of a Mobile 
Launcher Base and Launch Umbilical Tower. The.ML was also key component of the mobile 
launch concept and was used to support stacking operations in the VAB, transportation to the 
pad and launch operations. Interfaces to the vehicle were provided via nine swing arms and 
four hold-down arms. The sing arms provided access and service to the vehicle such as fluid 
and gases (kerosene, LOX/Hydrogen, helium, nitrogen, etc.); ground power communications 
and data. 

• Mobile Service Structure (MSS): Originally conceived as an arming tower, the MSS evolved 
to support late vehicle access requirements at the pad following roll-out.. 

• Crawler Transporter: The third key element of the mobile launch concept is the Crawler 
Transporter. Following trade studies that examine rail and barge options to transport the 
Mobile Launcher and Saturn V to the Pad, ground system developers selected a tracked 
vehicle concept based on large steam shovels used to mine surface coal. The Crawler 
Transporter consists of 8 steel tracks driven by 16 electric motors. Electric power is provided 
by four 1,000 kw generators, driven by two 2,750hp diesel engines. There are also two 750 
kw generators powered by two 1,065 hp diesel engines used for jacking, steering, lighting, 
and ventilating. 30 Two Crawler Transporters were built on site for Apollo. 

Launch Operations Ground Systems 

• Launch Pads: The two Saturn launch pads consist of a concrete base; -flame trench; liquid 
hydrogen, liquid oxygen and kerosene fueling systems; and a steel flame deflector. Each 
of the two Saturn V Launch Pads was constructed with over 68,000 cubic yards of 
concrete. The ramp leading up to the pad is inclined at a 5% grade and the flame trench 
is 42 ft deep; 450ft long and 58 ft wide 31 . 

A Mobil Launcher, Mobile Service Structure and Saturn V are shown on the Pad below in Figure 

24. 
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Figure 24: Mobile Launcher, Mobile Service Structure and Saturn V on the Pad 
2.4 Space Shuttle 

As early as the 1965, four years prior to the first Apollo lunar landing, NASA administrator 
James Webb formed the ‘Future Programs Task Group’ to beginning planning for missions 
following Apollo. The report described continued exploration of the moon beyond what was 
already planned for Apollo, orbiting space stations and manned exploration of Mars leveraging 
off the substantial capabilities provided by the Saturn launch vehicle family and Apollo 
spacecraft 32 . Later, in 1969, the Space Task Group established by President Nixon called for 
development of new capabilities for operating in space at substantially lower costs. The 
recommendations included in the report eventually led to the abandonment of the Saturn launch 
vehicles and Apollo spacecraft following the Skylab and Apollo-Soyuz Test Program. On 
January 5, 1970 President Nixon approved the Space Transportation System more commonly 
referred to as the Space Shuttle. 

Given the sensitivity for cost, it would seem the reuse of ground systems would make KSC an 
obvious choice for supporting both launch and landing operations for the Space Shuttle. 
Following the program’s approval, however, over 40 states and 150 sites, including New 
Mexico, Texas, Utah and Oklahoma, lobbied to be selected as the launch and landing site for the 
Shuttle. The selection of the Solid Rocket Boosters over liquid fly-back booster variants limited 
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the feasible candidate sites to coastal areas. Vandenberg Air Force Base (AFB) was selected for 
Shuttle Missions requiring polar orbits. Costs of new facilities, regional environmental impacts 
including sonic booms rocket exhaust and workforce issues were all factors considered during 
the evaluations. Screening to meet major mission and site requirements resulted in two final 
candidate options: Matagoraa, Texas and existing east/west coastal sites - KSC and Vandenberg. 
AFB. Due largely to the same factors that led to the selection of KSC for Apollo-Satum V 
launches such as flexibility with launch azimuths, the ability to launch directly over water and 
the existing infrastructure led to the selection of KSC for Shuttle launch and landing operations 
on April 14, 1972 33 . 

Flight Hardware Configuration 

The Space Shuttle consists of three major flight hardware elements: the Orbiter; External Tank 
(ET); and Solid Rocket Boosters (SRBs). The Space Shuttle can carry a crew of up to seven 
astronauts and deliver payloads weighing up to 55,000 pounds to low earth orbit. The Orbiter 
and Solid Rocket Boosters (SRBs) are re-usable. Each Orbiter is approximately 122 ft in length; 
has a wing space of 78 ft and is 58 ft tall. The Orbiter weighs approximately 240,000 pounds at 
liftoff has a payload bay 1 5 ft wide by 60 feet long. The Orbiter propulsion system consists of 
three LOX/Hydrogen Space Shuttle Main Engines and two hypergolic Orbiter Maneuvering 
System (OMS) Engines. Hypergolic reaction control thrusters are contained in the Forward 
Reaction Control System and in the two OMS Pods. The Obiter thermal protection systems 
consist of over 30,000 unique ceramic tiles, thermal blankets, and reinforced carbon-carbon 
panels located on the nose and leading edge of the wings. Each SRB consists of a reusable four 
segment solid rocket motor; Aft Skirt; Forward Skirt; and Frustum. Each SRB weighs 1,300,000 
pounds at launch and provides 3,300,000 pounds at launch. The SRBs are jettisoned at about 
220,000 feet and are recovered 120 miles down range from KSC. The ET is about 158 feet tall 
and 27 feet wide. The ET is loaded with 143,000 gallons LOX and 385,000 gallons of Liquid 
Hydrogen at launch. LOX and Hydrogen is supplied to the Orbiter Main Engines via two 17 
inch wide feed lines. The ET is jettisoned approximately eight and a half minutes into flight and 
impacts the Indian or Pacific Oceans depending on the launch azimuth. They are not re-used. 
The Space Shuttle System is shown in Figure 25: 
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Figure 25: Space Shuttle Rolling from VAB 

Ground Operations Concept 

The Shuttle was the first launch system designed to be reused. All Space Shuttle elements are 
processed, launched and refurbished at KSC- 

KSC Ground Processing begins immediately after landing at the Shuttle Landing Facility (SLF) 
at KSC or Edwards Air Force Base in California. Ground operations personnel dressed in 
protective equipment and breathing gear verify no hazardous vapors are present following 
landing. The flight crew egresses the Orbiter and final vehicle safing operations are performed 
prior to rolling the vehicle to the Orbiter Processing Facility (for KSC landings) or the 
Mate/Dem-mate device for California Landings. For California Landings, the Orbiter is mated 
to a specially modified 747 and returned to KSC via the SLF. Inside the Orbiter Processing 
Facility, the OMS and RCS pods are removed and taken to the Hypergolic Maintenance Facility 
for serving. Space Shuttle Main engines are removed and taken to the Main Engine shop for 
inspections and servicing. Dozens of other systems are serviced including: Electrical Power 
Distribution; Electrical Power Generation; Lighting; Life Support Systems; Thermal Protection; 
Data Processing Systems; Guidance, Navigation, and Control; Main Propulsion 


- 43 - 



APU/Hydraulics; Landing Gear; Mechanical Systems; Docking System; Communications 
Systems; Instrumentation; Escape/Crew Systems; Structures; Displays and Controls; and 
Remote Manipulator System. The Orbiter is then rolled over to the VAB for stacking. 

The ETs arrive at the Turning Basin via barge from the Michoud Assembly Facility in Louisiana 
and are transported to ET check-out cells in the VAB for inspections. SRBs are recovered by 
two specially design retrieval ships about 120 mile down range from KSC. They are brought 
back to Hanger AF (located on CCAFS), inspected, disassembled and cleaned (removing all 
residual solid rocket propellant). Solid Rocket Motor Segments are transported back to Utah 
where they are refurbished and re-loaded with propellant. The Aft Skirts, Forward Skirts and 
Frustums are transported to the Assembly and Refurbishment Facility where they are prepared 
for a future flight. Since 1998, most Space Shuttle Missions support construction and operations 
of the International Space Station. Therefore, most payloads are processed in the Space Station 
Processing Facility (see next section). The Elements are transported to the Launch Pad where 
they are installed in the Orbiter’ s Payload bay via the Payload Change-out Room on the Launch 
Pad. 

Integrated Operations begins once the SRB stacking operations are complete on the Mobil 
Launch Platform in the VAB. The ET is removed from the check-out cell and mated to the 
SRBs. The Orbiter rolls over from the Orbiter Processing Facility and Mated to the External 
Tank. Integrated tests are performed within a week and the Space Shuttle Stack is rolled to the 
Pad via the Crawler Transporter for final checkout and launch. 

The entire Shuttle processing flow is shown in Figure 26: 
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Figure 26: KSC Space Shuttle Processing Flow 


Ground Systems 

Offline Spacecraft Ground Systems 

• Orbiter Processing Facility: The OPF consists of three hanger-like processing bays. 
Each processing bay contains access platforms which surround the orbiter and allow 
interior access; environmental, emergency exhaust and fire protection systems; fixed 
cranes; a zero-G counterweight device for payload bay door operations; Launch 
Processing System (LPS) computerized checkout interface equipment with the Launch 
Control Center (LCC); shops; material service center; and mechanical and electrical 
support equipment. 

• Hypergolic Maintenance Facility (HMF): The HMF contains test cells equipped with 
cranes; access platforms; emergency exhaust and fire protection systems; and a small 
Launch Processing Systems set for the test, maintenance, modification and repair of 
orbiter hypergolic control system modules (OMS and FRCS). 
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Offline Launch Vehicle Ground Systems 

• Rotation, Processing and Surge Facility (RPSF): Consists of four facilities located north 
of VAB including the Rotation/Processing Building, two Surge Buildings and a Shop 
Building. The Rotation/Processing Building supports aft booster buildup with work- 
stands, 200-ton overhead bridge cranes, and a rail track which traverses through the 
building (SRB segments are shipped to KSC via rail). Two surge buildings are used for 
storage of processed Solid Rocket Motor (SRM) components prior to stacking. 

• Assembly and Refurbishment Facility (ARF): Performs non-propellant Solid Rocket 
Booster processing functions including assembly and tests forward skirt, aft skirt, 
frustum, nose cap, and thrust vector controls. Contains numerous labs, test areas, and an 
ordinance area for installing booster separation explosives. 

Integrated Operations Ground Systems 

• Vehicle Assembly Building (VAB): After Apollo, platforms in the High bays 1 and 3 
were modified support stacking of the SRBs, ET and Orbiter. ET check-out cells were 
added to high bays 2 and 4. Initial refurbishment of the Aft Skirts, Forward Skirts and 
Frustums was performed in the VAB Low Bay before construction of the Assembly and 
Refurbishment Facility. 

• Mobile Launch Platform (MLP): All three Apollo Mobile Launchers were modified to 
support Shuttle Operations. The Launch Umbilical towers were removed and exhaust 
exit holes were modified to accommodate the Shuttle SRBs and SSMEs. 

• Crawler Transporter: The CT was essentially unchanged from Apollo. Periodic 
technology upgrades were preformed to modernize electronic systems. 

• Launch Control Center/Launch Processing System: All computing equipment from 
Apollo was removed and replaced with the new Launch Processing System (below). 

• Launch Processing System (LPS): LPS is used to support offline orbiter operations; 
stacking operation in the VAB and launch operations on the Pad. It consists of three 
subsystems including the Checkout, Control and Monitor Subsystem (CCMS); Shuttle 
Data Center; and Record and Playback Subsystem. CCMS Sets are located in all four 
Firing Rooms and consists of consoles driven by distributed real-time computers linked 
via a custom shared memory system. Application Software written in Ground Operations 
Aerospace Language (developed for Shuttle in the 1970s) runs on computers in the 
CCMS. The CCMS is the primary means to command and monitor Shuttle operations. 
The SDC is based on UNIX servers and is used for three major functions: data recording 
and retrieval; operational software builds for CCMS; and Shuttle Ground Operations 
Simulator used for launch team training and software check-out. The RPS is used for 
analog and digital recording of raw measurement data received from the Orbiter. 

Landing and Recovery Operations Ground Systems 
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• Shuttle Landing Facility (SLF): Consists of concrete runway 15,000 feet long, and 300 
feet wide with a 1 ,000 foot paved overrun at each end with landing system aids. Landing 
Systems include Tactical Air Navigation (TACAN), Microwave Scanning Beam Landing 
System (MSBLS) and xenon lighting systems. The Mate/De-mate device is located on 
the ramp at the SLF and is used to remove the Orbiter from the Shuttle Carrier Aircraft 
following landings in California. 

• SRB Retrieval Ships: Two SRB retrieval ships are 176 feet in length, 37 feet in width, 
and draw about draft of about 1 2 feet. Each ship displaces 1 ,052 tons and is driven by 
two main engines providing a total of 2,900 horsepower. 

Launch Operations Ground Systems 

• Launch Pad: Both Launch Pads A and B were modified to support Shuttle Operations. 
Some of the modifications included the addition of the Fixed Service Structures (FSS); 
Rotating Servicing Structure (RSS); Sound Suppression System; Hypergolic Fuel Farms 
and new control and data acquisition systems. The RSS contains the Payload Change-out 
Room (PCR) and provides a clean work area to install payloads into the Orbiter Payload 
Bay. The FSS also provides weather protection to the Orbiter. 



Figure 27: Payload Canister Lifted into PCR [NASA] 

Shuttle Support Equipment and Ground Support Equipment 
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The ground systems described above certainly represent the most visible components of the 
facilities and equipment required to support Shuttle Operations. However, each of the ground 
system contains hundreds of SE and GSE components. There are over 4000 ‘Program Model 
Numbers’ (discrete types of GSE) for Shuttle GSE alone. Each Examples of GSE range from 
simple RCS covers to complex avionics test equipment. Each type of SE and GSE require 
sustaining engineering and logistical support. In the Shuttle Logistics facilities at KSC, there are 
over 1 80,000 parts. 


2.5 International Space Station 

Manned space stations orbiting the earth were part of the earliest visions for space travel as far 
back as the 1869 when Edward Everett Hale described a “Brick Moon” with a crew of 37 
orbiting the earth assist crews in navigating the seas for the Atlantic Monthly 1 4 . A space station 
was also called for in the Space Task Group report of 1969 35 . The construction and operation of 
a low earth orbiting space station was one of the primary reasons for developing the Space 
Shuttle. However, NASA’s budget in the 1970s would not support simultaneous development of 
both the Space Shuttle and space station. It was not until 1984, when President Reagan 
announced plans for a new orbiting space station, did detailed concept development begin. The 
new space station was called Freedom and was to be constructed and serviced by the Space 
Shuttle. Following seven major redesigns, three presidential administrations, and six congresses, 
Space Station Freedom was effectively canceled in 1993. President Clinton directed NASA to 
partner the development of the Space Station with Russians in addition to the Europeans and 
Japanese who were already supporting Freedom. The new program was called the International 
Space Station. The first Space Station Assembly flight occurred with the launch of Zarya in 
1998 on a Russian Proton launch vehicle. Two weeks later, the Space Shuttle Endeavour 
delivered the first U.S. element, the Unity Node. Assembly continued through 2002 until the 
Columbia accident grounded the Shuttle Fleet in 2003. Space Station assembly was resumed in 
2005. 

Space Station flight hardware elements are delivered to orbit by the Space Shuttle and Russian 
launch vehicles such as the Proton. When complete, the Space Station’s mass will be over 
400,000 kg and have a volume of over 1,200 m 5 Space Station construction is nearing 
completion as shown in Figure 28. 
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Figure 28: ISS Flight Hardware Configuration [NASA] 

Ground Operations Concept 

All US, European and Japanese elements are designed to be delivered to orbit via the Space 
Shuttle and therefore are processed and launched at KSC. Elements arrive via land, sea or air 
and are transported directly to the Space Station Processing Facility (SSPF) for pre-launch 
check-out, integration and testing. Processing activities performed at KSC include: assembly of 
hardware; integration of components and sub-systems; pre-flight fluids servicing; subsystem and 
element standalone testing; Multi Element Integrated Testing (MEIT); flight acceptance 
requirements verification; crew equipment interface testing; on-orbit constraints testing; and 
Shuttle interface testing. Pre and post launch processing of the reusable Multipurpose Logistics 
Modules (MPLM) and ISS research experiments are also conducted in the SSPF. Once 
integration testing is complete, the element is loaded in the specially designed payload canister 
and transported to the either Obiter Processing Facility or launch pad for installation into the 
Orbiter payload bay. The end-to-end flow is shown below in Figure 29. 
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Figure 29: ISS Element Processing Flow [NASA] 


One unique aspect of Space Station processing at KSC is the Multi-Element Integration Test 
(MEIT). Early in ISS program, a ‘ship and shoot’ philosophy was assumed for the flight 
hardware. Ship and shoot implies flight hardware arriving at KSC is essentially flight ready 
without the need for standalone or integrated tests. As the program matured and the risks of the 
Ship and Shoot approach emerged during the design process, a series of MEITs were planned 
and conducted to validate the operation of the flight elements and their systems in an 
environment that is as flight-like as possible.. The MEITs also demonstrated interoperability and 
functionality of Space Station elements as integrated “in-space” assemblies before they were 
assembled in space for the first time 36 . MEIT hardware configure is shown below in Figure 30. 
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Figure 30: MEIT Test Configurations [NASA] 

Ground Systems Configuration 

An ambitious assembly sequence was proposed early in the program requiring a number of 
Space Station Flight elements to be processed simultaneously at KSC. The Space Station 
consisted of a wide variety of flight hardware elements each requiring specific ground system 
configurations. Several ground processing trade studies were conducted that determined existing 
ground systems such as the O&C building could not support planned element flight rates and 
processing requirements. To accommodate the new requirements, the Space Station Processing 
Facility was constructed in the early 1990s. The facility includes two processing bays, an 
airlock, operational control rooms, laboratories, logistics areas, and office space. The processing 
bays are capable of maintaining a 100K class clean work area and includes services for 
compressed air, gaseous nitrogen, oxygen, helium, electrical power, ammonia monitoring, etc. 
Unlike the O&C high bays used for the Apollo and early Shuttle payload processing, the SSPF 
processing bays were designed to flexible with movable work platforms to allow a variety pre- 
launch test configurations. Flight hardware is supported by movable work stands such as Launch 
Package Integration Stands, Element Rotation Stands and Cargo Element Work Stands. GSE 
includes fluid serving carts, lifting slings, ground power modules, flight hardware simulators, 
etc. Automated check-out is provided by the Test, Control and Monitor System (TCMS). The 
system is based on commercial-off-the shelf (COTS) Unix Work Stations, Servers and VME 
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based real-time control/data acquisition systems. Ground systems and ISS flight elements used 
for the second MEIT in the SSPF high bay are shown below in Figure 31. 



Figure 31: MEIT 2 Underway in the SSPF [NASA) 


2.6 Constellation 

The Constellation program was initiated as part of the Nation’s Vision for Exploration (VSE) 
announced in January 2004. The vision established a new direction for the US Space Program 
leading to renewed human exploration of the Earth’s moon by 2020 and eventual exploration of 
Mars. Virtually every program and project within NASA was affected by the announcement as 
resources within the agency were refocused on the new objectives contained in the vision. Some 
of the more significant objectives included in the announcement include: the retirement of the 
Space Shuttle following completion of the International Space Station (ISS) in 2010; the 
development of a new Crew Exploration Vehicle (CEV) to carry astronauts first to the 
International Space Station and on to the moon; renewed robotic exploration of the moon and 
continued robotic exploration of the solar system including mars; and the development of a 
commercial capability to resupply the International Space Station. 

The development of the spacecraft, launch vehicles and ground systems required for supporting 
missions to ISS and moon is the responsibility of the Constellation Program. The Constellation 
Program consists of several flight and ground operations projects including Orion, Ares, Mission 
Operations and Ground Operations. 

In 2005, NASA completed the Exploration Systems Architecture Study (ESAS) that established 
initial ISS and lunar mission profiles and the flight hardware architecture currently under 
development by the Constellation Program. Since completion of the study, the flight hardware 
and ground systems projects have made significant progress. High level descriptions of 
spacecraft, launch vehicle and ground systems are included below. 
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Spacecraft Elements 


Orion Crew Exploration Vehicle (CEV) accommodates up to six crewmembers for missions to 
ISS and up to four crew members for lunar missions. It is designed to operate for up to 210 days 
in earth or lunar orbit. It consists of the Launch Abort System (LAS), Crew Module, Service 
Module and Spacecraft Adapter as shown in Figure 32. 



Spacecraft Adapter 


Figure 32: Orion Crew Exploration Vehicle (CEV) [NASA) 

The Lunar Lander is still in the early phases of concept development. When complete, it is 
expected to provide the capability to land a crew of 4 on the lunar surface for missions lasting 
initially from 7-14 days; provide the capability to land 500kg of cargo on crewed missions and 
return up to 100kg of lunar samples to the CEV. It will also be able land autonomously in a 
cargo only mode. The crewed version of the Lander will consist of an Ascent Module, Descent 
Module and Airlock. The current lander concept is shown below in Figure 33. 
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Figure 33: Altair Lunar Lander Concept [NASA] 

Launch Vehicle Elements 

The launch vehicles for the Constellation Program are the Ares I and Ares V. The architecture 
utilized commonality between programs and leveraging off heritage hardware from the Apollo 
and Shuttle. Both vehicles will utilize 5 segment versions of the Shuttle Solid Rocket Boosters 
and an upgraded Apollo J2 engine as shown below in Figure 34. 


- 54 - 


120 


E 


90“ 



i 

r 


r 


Upper Stage 
(1 J-2X) 

127Mt LOx/LH 2 


i • 5-Segment 
Reusable 
T Solid Rocket 
i Booster 
fr (RSRB) 


Ares I 



Crew 


Lander 


S-1VB 


nr 


(1 J-2 engine) 

IIOMt Lox/LH 2 


S-41 

(5 J-2 engines) 

450Mt LOx/LH 2 



Ares V 


Saturn V 


Height: 56m Height: 98m 

Gross Liftoff Mass: 2040Mt Gross Liftoff Mass: 910Mt 


Height: 109m 

Gross Liftoff Mass: 331 OMt 


Height: 111m 

Gross Liftoff Mass: 2950Mt 


25Mt to LEO 22Mt to LEO 53Mt to TLI 

65Mt to TLI in Dual- 
Launch Mode with Ares I 
131 Mt to LEO 


45Mt to TLI 
1 1 9Mt to LEO 


Figure 34 : Constellation Flight Hardware Commonality with Apollo and Shuttle [NASA] 


For lunar missions, the crew will be launched into low earth orbit by the Ares I. Altair and the 
EDS will be launched by the Ares V within 24 hours. Orion will dock with Altair/EDS in LEO. 
The EDS will perform the trans-lunar injection bum for the 3 day journey to the moon. As the 
spacecraft nears the moon, the EDS will be discarded and Altair will perform the lunar orbit 
injection bum. The entire crew transfers to Altair, undocks from Orion and lands on the lunar 
surface. The crew performs lunar surface activities initially from 7-14 days then departs from 
the lunar surface via the Ascent Module and re-docks with the Orion waiting in lunar orbit. The 
Orion Service Module performs the trans-earth injection bum. Once Orion nears the earth, the 
Service Module is jettisoned, the Crew Module re-enters the earth’s atmosphere and lands near 
the south west coast of California for recovery and retrieval operations. The Lunar Mission 
profile is shown graphically below: 
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Figure 35: Constellation Lunar Mission Profile [NASA] 


Constellation Ground Operations 

A phased approach is planned for the development of Ground Systems to support missions to the 
International Space Station and to moon. The first phase is referred to as ‘Block 1 ’ and includes 
the required capabilities to process and launch the Orion Spacecraft and Ares I launch vehicle for 
missions to the International Space Station. The second development phase is referred to as 
‘Block 2’ and includes additional capabilities to process the Lunar Lander (Altair) and the Ares 
V cargo launch vehicle. The section includes descriptions for both Block 1 and Block 2 ground 
systems. 

Ground Operations Concept 

The ground operations concept for both Ares I/Orion and Ares V/Orion leverages of the mobile 
launch concept developed for Apollo subsequently used in Shuttle. Launch Vehicle and 
Spacecraft elements are turned over to Ground Operations following manufacturing and 
assembly for preflight processing and launch. The overall processing flow for Ares I/Orion is 
shown in the following Figure: 
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Figure 36: Ares I/Ground Processing Flow [NASA] 

Ground processing concepts for the Ares V and Altair shown in the Figure 37 below are based 
on preliminary Launch Vehicle and Spacecraft vehicle configurations. Several launch vehicle, 
spacecraft and ground processing trade studies were underway at the time of this writing. 
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Figure 37: Ares V/Altair GS Flow [NASA) 


One notable exception to Apollo and Shuttle ground processing flows is the amount of 
processing time required for the integrated stack while at the launch pad. Many operations 
performed at the launch pad are critical path and any problems encountered during those 
operations increase the likelihood of launch delays. Furthermore, access requirements increase 
as the number of operations at the launch pad increase thus requiring additional ground systems 
at the pad exposed to the sea side environment. The Apollo Mobile Service Structure and 
Shuttle Fixed Service Structure are examples of such ground systems. Annual operations and 
maintenance costs for maintaining structures located immediately next to the coast are higher 
than those protected in an enclosed environment such as in the VAB. Analysis of Apollo and 
Shuttle workflows indicate a benefit to minimize on pad time as much as possible.. One 
operation in particular is spacecraft hypergolic loading. During the Apollo and Shuttle 
programs, hypergolic loading was performed at the pad. Only essential personnel properly 
trained and protected in Self Contained Atmosphere Protective Ensemble (SCAPE) Suits are 
allowed in the area. No other operations at the pad were allowed during propellant loading. In 
Constellation, hypergolic loading of the Orion spacecraft will in occur in the Mult-Payload 
Processing Facility (MPPF) removing a critical path task from the pad processing. 

Constellation Ground Systems Architecture Overview 
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The Constellation Ground System consists of Facilities, GSE and Support Equipment required 
for performing services at the launch, landing, and retrieval sites. As with Apollo, Shuttle and 
ISS, functions provided by the Ground System include receipt of flight hardware elements, 
software, cargo, and ground support equipment; off-line spacecraft and launch vehicle 
processing; spacecraft and launch vehicle integration; launch operations; spacecraft recovery and 
retrieval; contingency operations such as search and rescue; and logistics functions. The overall 
Constellation architecture is broken down into levels. Launch vehicles, spacecraft and ground 
systems are considered ‘Level III’ systems for the purposes of system wide architectural 
decomposition. Each system is then broken down into ‘Level IV’ elements. The Ground System 
is broken in down into 8 elements as shown below in Figure 38. 



RalroM 
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Figure 38: Constellation Ground System Architecture [NASA] 

Spacecraft Processing Element: Consists of facilities, FSE, GSE and SE required to perform off- 
line processing of the Orion and Altair Spacecraft. Final manufacturing and assembly occurs at 
KSC under the direction of the Orion Project at the Johnson Space Center who is responsible for 
the production of the Orion spacecraft. Although the activity occurs at KSC, it is not considered 
part of ground operations. The partially integrated spacecraft is turned over the Ground 
Operations Project prior to transportation from the O&C High Bat to the Multi-Payload 
Processing Facility (MPPF). The Orion Spacecraft is partially integrated during final 
manufacturing and assembly in the Operations and Check-out building at KSC. The MPPF 
provides a clean work area, space for work stands and access platforms services required to 
perform off-line check-out of the integrated Orion Crew Module, Service Module and Spacecraft 
Adapter. Offline operations are supported by Multi Mission Support Equipment and consist of 
transporters such as the KMAG, tugs and dollies; handling equipment; strong backs and lifting 
slings. Prior to transportation to the VAB for integrated operations, hypergolic propellants are 
loaded on the spacecraft. Similar operations are planned for Altair and are planned to take place 
in the Space Station Processing Facility. 
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Figure 39: Spacecraft Processing Elements [NASA] 

Solid Rocket Processing Element (SRPE): Consists of facilities, FSE, GSE and SE required to 
perform off-line processing of the Ares I First Stage. The First Stage consists of a five-segment 
Solid Rocket Booster derived from the Space Shuttle. The existing SRB Rotational Processing 
and Surge Facility, GSE and SE will be reused from the Space Shuttle Program to support Ares 
I. An additional Surge Facility (for SRB segment storage) and GSE will be required to support 
Ares V SRB element processing. The SRPE also consists of the Assembly Refurbishment 
Facility (for SRB Aft Skirts, Frustum, Forward Skirts, Nose Cap and Thrust Vector Controllers), 
and Parachute Refurbishment Facility (PRF). SRBs recovered following flight are returned to 
Hanger AF for post flight inspections and disassembly. Once residual propellant is removed, 
SRB segments are sent by rail back to the manufacture to be refurbished refilled with propellant. 
The Aft Skirts, Forward Skits, Frustum and Nose cape are transported by road back to the ARF. 

Vertical Integration Element: The VIE consists of facilities, FSE, GSE and SE required to stack 
and integrate the Ares launch vehicles with Orion and Altair spacecraft. The Vertical Integration 
Element is allocated to the Vehicle Assembly Building and the existing KSC Barge Terminal. 
The Ares I Upper Stage and Ares V Core Stage arrive at KSC via the Barge Terminal and will be 
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moved directly into the VAB. A ‘ship to integrate’ philosophy is planned for the Ares I upper 
stage and Ares V Core Stage. Minimal offline processing is planned for these two elements. 

The current Ground Operations baseline includes one VAB high-bay for Ares I processing and 
one VAB high-bay for Ares V processing. The VAB provides interfaces to the ML and access to 
the Ares I and Orion/LAS via movable work platforms. Examples of the facility services include 
cranes, access platforms and lightning/weather protection. For Ares I/Orion stacking, the VAB 
will be used to integrate the Orion Launch Abort Systems to the CM/SM/SA; stacking and 
mating of the Ares I First Stage Solid Rocket Booster segments; mating of the Upper Stage to the 
First Stage; and stacking mating of the Orion/LAS to the Ares I Upper Stage. Integration tests 
are performed with the entire stack prior to role-out to the launch pad. Concept drawings for the 
Ares VAB high-bays are shown below. Note the extensible platforms for the Ares I and Ares V. 
The platforms represent the most significant component of the VAB modifications required for 
Constellation. 




Ares I VAB High-Bay Ares V VAB High-Bay 

Figure 40: Ares VAB High-bay Concepts [NASA] 

Mobile Launch Element: The Mobile Launch Element consists of two systems: the Mobile 
Launcher and Crawler Transporter. The Mobile Launchers provides the structure and equipment 
required to stabilize, integrate, test, service, transport, and launch the integrated stack. The 
launch vehicle is attached to the Mobile Launcher Base. The Mobile Launch Tower (MLT) 
provides access and services to the spacecraft and launch vehicle via swing arms. For Ares 
I/Orion, the MLT provides a crew access arm for astronaut ingress and egress from the 
spacecraft. The MLT also provides the flight and ground crews access to the emergency egress 
system on the launch pad. Due to the substantial differences in configuration between the Ares I 
and Ares V, the Mobile Launchers are unique as shown in the following concept drawings. 
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Ares I Mobile Launcher 


Ares V Mobile Launcher 


Figure 41: Concepts for Constellation Mobile Launchers [NASA] 


The Crawler Transporter used during the Apollo and Shuttle Programs will be reused for 
Constellation Ares I/Orion missions to ISS. Modifications may be required for Ares V 
depending on the combined weight of the Ares V and Ares V Mobile Launcher. 


Launch Pad Element: The Launch Pad Element consists of both Launch Complex Pads 39A and 
39B. Pad B will be used to support Ares I/Orion and Pad A will be used to support Ares 
V/Altair. In conjunction with the Mobile Launchers, each Launch Pad provides the necessary 
services and structure to support pre-launch and launch operations. The launch facilities include 
cryogenic propellant storage and servicing equipment, electrical systems, a flame trench and 
flame diverters, a safe haven for emergency egress, the fixed portion of the Emergency Egress 
System, lightning protection for the integrated stack and Mobile Launcher, weather data 
instrumentation, pneumatic service and storage, pressurant service and storage, heating, 
ventilation, and air conditioning (HVAC), potable water, breathing air, accommodation for the 
Paging and Area Warning System (PAWS), and electrical systems. 
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Figure 42: Constellation Ares I Pad [NASA) 

Spacecraft Recovery and Retrieval Element (SRREL The SRRE provides ground systems to 
support recovery and retrieval of the Orion Crew Module. This element is the only element that 
will predominately be used beyond the physical boundaries of KSC at the Orion Recovery and 
Retrieval Sites. The nominal landing mode for Orion is on water near the southern California 
coastline. Orion will also be cable of contingency land landings. The SRRE includes ships, 
cranes, handling equipment, access equipment, and an aircraft to safely recover the flight crew 
and Orion Crew Module. 

Command. Control & Communications Element (CCCE1: The Command, Control and 
Communications Element contain control center facilities, command and control systems, and 
communication systems. The Launch Control Center is the primary control facility and contains 
4 control rooms. For Constellation, only two of the four control rooms are planned to be used. 
Control room one will support Ares I/Orion and control room four will be used for Ares 
V/Altair. The primary Command and Control System for off-line spacecraft operations and all 
integrated stack operations in the VAB and on the launch pad is the Launch Control System 
(LCS). LCS sets will be located in the MPPF and Launch Control Center. The Complex Control 
System (CCS) is used to monitor and control facility systems such as HVAC, Pneumatics, Firex, 
Power and Oxygen Monitoring Systems in the Vertical Integration Element. Communication 
systems include voice, video (imagery), and data systems which interface with the flight systems, 
the (CCS), and other GS elements. CCCE is supports operations in all other ground system 
elements, a characteristic unique to Command, Control and Comm Element. 
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Figure 43: Command, Control and Communication Element [NASA] 

Interfaces between LCS the VIE, LPE and SPE are shown in the following Figure 44 below. 
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Figure 44: LCS Interfaces [NASA] 
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Operations Support Element (OSE): The OSE captures a diversity of systems and functions 
required to support the launch site such as logistics, base operations services and coordination of 
services provide by the local community. Logistics includes warehousing facilities; 
initial/replenishment/spares acquisition; material and inventory management systems; depot 
operations such as propellants and life support commodities and spacecraft recovery 
transportation. Base operations services includes weather services and onsite meteorological 
systems; KSC emergency planning and response, base security, integrated operations 
management systems such as Integrated Work Control Systems, environmental management, 
and KSC transportation infrastructure (roads, rails, air). The OSE also coordinates and ensures 
compatibility between on-site systems and local emergency response organizations. 

Constellation Ground System Interfaces 

The elements work in conjunction to perform ground operations at the launch site and landing 
and recovery sites. Interfaces between the elements and systems external to KSC Ground 
Systems is shown below: 



Figure 45: Ground Systems Interfaces (Block 1 only) [NASA] 
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The elements map to the objects and processes described earlier in the chapter as shown in the 
following table: 


Table 1: Constellation Ground Systems Element Mapping to System OPD 


Constellation Ground System 
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Level 5 Subsystems 


The elements capture at the highest levels ground systems required to support offline processing, 
integrated operations and launch operations. Below the level IV elements are level V 
subsystems. Many of these subsystems support multiple elements. An ‘end to end’ description 
of a subsystem will often include subsystem components that are present in 2 or more elements 
as shown in Figure 46: 
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Figure 46: Level V Subsystems [NASA] 

Figure 46 shows only a subset of the over 70 level V subsystems currently under design for the 
launch site for Block I. The subsystems are divided into 9 categories. 

Table 2: Level 5 Subsystems 


Subsystem Category 

Number of 
subsystems 
within 
category 

Examples 

Fluids 

6 

Ares I Liquid Oxygen (L02) Fill and Drain System; Freon; 
Hypergolic Servicing/ De-servicing System 

Gases 

6 

Environmental Control System (ECS); Gaseous Helium; 
Gaseous Nitrogen 

Mechanical 

18 

Vehicle Assembly Building (VAB) Access Platforms; 
Handling and Access - VIE Equipment; Spacecraft 
Transporter; Emergency Egress System (EES) 

Electrical 

11 

Hazardous-Gas Leak Detection System; Radio Frequency 
Monitoring System; First Stage Thermal Control System 

Command and Control 

3 

Launch Control System (LCS); Portable Orion Avionics 
Integration Laboratory; Kennedy Ground Control System 

Communications 

7 

Operational Intercom System; Telephone System; Paging & 
Area Warning System 

Imagery 

3 

Operational Television; Broadband Communications 
Distribution System; Imaging System 

Facility 

22 

ML Structure (Base and Tower); Uninterruptible Power 
Supply; Cranes 

Miscellaneous 

2 

Laser Alignment System; Ordnance System 
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2.7 Current KSC Facility and Infrastructure Summary 

Today, the Kennedy Space Center (KSC) covers over 140,000 acres. Approximately 70,000 
acres of estuary are deemed a system of National Importance. Most of the land is actually 
managed by the U.S. Fish and Wildlife Service and is part of the Merritt Island National Wildlife 
Refuge. The Apollo, Klondyke and Playalinda beach areas north of Launch Pad 39B are part of 
the Cape Canaveral Seashore and are managed by the National Park Service. Only 6,800 acres 
are disturbed and directly support launch operations today. KSC infrastructure currently in place 
is summarized below: 

• Over 900 Facilities/ 7.6 million square feet of Building Area 

- 2 Launch Pads 

- 3 Fire Stations 

- 2 Medical Facilities 

• Energy and Gases 

- 3 Central Cooling/Heating Plants 

- 2 Primary Substations 

- 270 miles of Electrical Distribution Lines 

- 60 miles of high pressure Helium/Nitrogen Pipelines 

• Shuttle Landing Facility (1 5,000 foot runway) 

• 213 miles of Roadway 

• 2 Sea Docks 

• 40 miles of Railroad 

• 5 Major Bridges 

• Current Replacement Value as of 2008: S4.7B 
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The following Figure illustrates land use on the Kennedy Space Center and Cape Canaveral Air 
Force Station as of 2004. 
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Figure 47: KSC and CCAFS Land Use (2003) [NASA] 
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3 Literature Review 


Summaries from a broad range of articles addressing various aspects of commonality are 
provided to capture the dominate areas of research. An extensive search was performed in 
electronic libraries including the NASA Technical Reports Server, American Institute of 
Aeronautics and Astronautics ( AIAA), Engineering Village’s COMPENDEX, Institute of 
Electrical and Electronics Engineers (IEEE) Xplore, ENGnetBASE, etc. The primary goals of 
the search were to determine the degree commonality as applied to ground systems was 
addressed in literature; develop a set of terms and definitions; seek out potential analysis 
methods and to investigate challenges associated with applying commonality. 

3.1 Commonality Terms and Definitions 

The vast majority of scholarly work in literature is focused on commonality as applied to 
spacecraft systems planned for long-duration spaceflight to destinations such as the moon and 
mars. Kline and Bachman 37 developed a model to capture the effects of two types of 
commonality: components that are common across elements (e.g., spacecraft) and those that are 
common across subsystems within an element. The model addresses all mission phases with 
several co-located elements (meaning they can share spares for common items) as well as phases 
with elements that are not co-located and cannot share spares. Mass reductions ranged from 1 1 
to 32% depending on the assumptions for level of commonality. The models also suggest 33- 
50% fewer spares if the parts are reconfigurable or common across different mission elements 
for Mars missions. Commonality is considered at the component level only sharing the same 
hardware characteristics and functions. 

Siddiqi and de Week 38 developed a model that considers the ability to reconfigure hardware to 
also address mass and volume issues for space missions. The model assumes parts in elements 
are reconfigurable, are accessible and that they do not have to operate at the same time. By 
allowing temporary scavenging or cannibalization it was determined that availability with 
dedicated spares is lower than with reconfigurable spares. Differences did not seem to change 
when the number of spares increased of decreased. 

While most papers and plans define commonality in terms of design and physical form, 

Crawley, Hofstetter and Wooster 39 offer expanded definition to include fiinctional, architectural, 
operational, technology, design and reusability commonality. At a minimum, for two objects or 
systems to exhibit commonality they must possess same functions but not necessarily the same 
form. This forms the basis for a hierarchy beginning with the functional type. Similarities with 
respect to design and physical form increases as two objects exhibit architectural commonality. 
Thus similarities increase through each successive type (functional->architectural->operational- 
>technology->design->reusability). Crawley, Hofstetter and Wooster also suggest that as the 
level of commonality increases, so do benefits in terms of reduced DDT&E cost, reduced 
DDT&E risk, production cost, operations cost and operations risk. 
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3.2 Platform Based Product Development 

Platform-based product development allows for the development of several products originating 
from a single base design. By using common processes, infrastructure, design and parts, near- 
term development costs are lower when compared to the development of independent products. 
Commonality to some degree is achieved by reusing the platform across multiple products. Boaz 
and Crawley 40 describe sequential and parallel platform product development. In sequential 
product development, a single product is designed and produced by a single development team. 
Follow-on products based on the original platform are developed and produced later in time by 
the same or new development teams. While both approaches offer long-term life cycle cost 
benefits, for parallel platform the benefits are realized sooner than with the sequential approach. 
For the sequential case, the platform may be over optimized for the first product since 
requirements for follow on variants are still at concept level only and organizational emphasis is 
placed on the first product. 

3.3 Commonality and Ground Systems 

As stated in the introduction, no articles were found that specifically address commonality as 
applied to ground systems at any launch site (KSC, French Guiana, etc). A number of articles 
were found that address commonality in systems used in satellite ground systems. The vast 
majority of those articles were centered on software reuse in mission planning, data distribution, 
command and control, etc. 

Dussauze et. al. describe how the ground segments are developed today typically using one of 
three methods: by purchasing a Commercial Off the Shelf System and adapting for a particular 
application; by designing and building a custom solution; and by selecting the best of several 
products for each requirement function and integrating them. The third choice seems to offer the 
most cost effective way to optimize to a particular solution by allowing only the best products to 
be selected for a given function, the costs of integrating often negates the benefits despite the use 
of industry standards such as JAVA, C++, CORBA, etc. In an attempt to address these 
drawbacks, European Space Agency is leading an effort to define component interfaces that are 
driven by ‘provided services’ and ‘required services’ for each major function. EADS Astrium 
identified the following functions to be common within the ground segment across multiple 
satellite systems: Procedure Preparation and Execution; Plan Preparation and Execution; Flight 
Dynamics; System Database Management; and Ground Equipment Monitoring and Control. 

Satellite manufactures typically utilize proprietary test and check-out systems to develop, 
integrate and test a satellite with little to no regard of the systems that will be used to operate the 
satellite. Monham and Quigley 41 describe inefficiencies they call ‘cost hot spots’ in the transfer 
of operations knowledge during development and test of satellites. The process of building and 
transferring operations knowledge occurs in two major stages. During development, the satellite 
prime and subcontractors create multiple data bases and procedures to test components, 
subsystems, systems and eventually, the entire integrated satellite. The second stage involves the 
turnover of the satellite from the prime contactor to the operator. During this turnover, data 
bases and procedures developed for manufacturing and test are typically published in manuals or 
delivered to the operator on electronic media. The operator then must spend time and effort 
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importing these products and applying additional ‘ground segment constraints’ for use in the 
operators own mission control center. While Interface Control documents help to minimize the 
effort required for the transfer, efficiencies can still be. gained by increasing the use of common 
tools and standards. In an attempt to deal with these issues, European satellite operators and 
manufactures developed the Mission Operations Information System (MOIS). MOIS essentially 
provides a tool set to develop test and verification procedures and associated databases using a 
standard format. It allows the transfer of operations knowledge between both internal 
manufacturing teams as well as directly to the operators. Thus, efforts to develop and test 
procedures for manufacturing are directly transferable to the operator increasing the efficiency 
manufacturing and turnover of the satellite to the operator. 

Since Monham and Quigley’s article was first published in 2004, several other papers have 
continued to promote their approach using industry standard data bases and procedural 
languages. Chaudhri and Hollander 42 built on this and extend the notion of leveraging factory 
test and verification procedures for use in operations by promoting the use of industry standard 
data bases and procedural languages to achieve these efficiencies. Example data base technology 
includes SQL, Oracle, XML Telemetry and Telecommand Exchange (XTCE); example 
procedural languages include Spacecraft Test and Operations Language (STOL); ARES - 
Automated Real Time Execution Suite; and Procedure Language for Users in Test and 
Operations (PLUTO). 

Similar benefits were reported by Gilbert and van Leeuwen 43 . In their paper, they describe the 
extensive ground command and control infrastructure planned to support Europe’s largest 
contribution to the International Space Station, the Columbus Laboratory Module. The 
infrastructure is based on the Columbus Ground Software (CGS) originally used to perform 
integration and check-out of the flight hardware at the manufacturing facilities for development, 
simulation and software test. Twelve geographic ground operations locations are supported by 
CGS. The software supports the Columbus in space operations, Columbus flight control and 
payload operations coordination, on-site engineering support, off-site engineering support for 
astronaut training, and a variety of user support facilities. The primary objective for reuse of 
CGS is to ensure consistency between the development and operational phases. Costs are 
minimized by re-using data sets test procedures and models qualified during development and 
reducing training costs for staff. 

The reuse of software to achieve commonality benefits rarely materialize to the degree planned 
at the beginning of a project. McKerracher 44 et al note that early estimates of 50%-70% cost 
savings while actual savings are only 10%-20%. Often, project managers and developers fail to 
consider the effort required to update requirements documents, re-write test procedures, re- 
perform tests, etc. McKerracher describes the ‘Common Ground Approach’ for developing 
common ground systems to support science missions. The approach begins with constraining the 
development of the top-level system requirements, architecture and concept of operations to 
ensure divergence between missions is significantly reduced. Re-use is addressed at several 
levels in the development process including concepts, requirements, architecture, interfaces, 
design, code, test plans and user guides. A product line methodology is used to align common 
ground effort across mission and along functional areas. Development processes were also 
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strictly managed. Requirements were stored in a common data base and version control was 
placed on commercial off the shelf and ‘government off the shelf products’. 

3.4 Challenges with the Application of Commonality 

The benefits of commonality in terms of reduced lifecycle costs during both development and 
operational phases of a program are generally widely accepted. However, in a number of cases, 
the level of commonality declines as the program matures. Boaz and Crawley 45 describe an 
attribute of commonality called divergence: They attribute divergence to changing requirements; 
learning in development and operations; availability of new technologies; and obsolescence. For 
platform based products, the lack of coordination across products; intentional pursuit of point 
designs; misalignment between program lifecycle phases are all given as reasons for divergence. 
An example of a program that experience divergence was the TFX (Navy Tactical Fighter, 
Experimental) program in the 1960s where commonality levels dropped from 100% to contractor 
designs with 84% commonality, to 61% commonality and finally, to no commonality. 

Chaudhri and Hollander 46 note several risks of standardizing ground data systems including 
increased upfront design time, timing issues between full definition of requirements versus 
acquisition windows and unknowns with the impact to legacy systems. Vendor reluctance to 
adopt new standards, lack of fully closed business case and compatibility with government 
acquisition processes were also listed as obstacles. Herrera 47 describes challenges with 
coordinating across multiple concurrent programs. A form of divergence is caused by some 
missions freezing baselines while common elements continue to evolve. The high level of 
resources required to properly staff the upfront development effort was also described as an 
impediment. To overcome organizational barriers with implementing commonality, Egbett and 
McKain 48 describe how Allison assigned an individual to be specifically responsible for ensuring 
and maximizing commonality across a line of turboprop and turbofan engines. Requests to 
deviate from commonality goals required specific approval from company senior management. 

Commonality was an early goal for the International Space Station program. Ney and Looper 49 
noted significant problems with achieving commonality goals due to the number of contractors 
involved and the lack of a program-wide system integration organization. It was believed that an 
integration organization with sufficient technical resources and with the proper organization 
authority at the program level could perform the appropriate trades between the desired degree of 
commonality and cost/technical performance. Other reasons considered in the Ney and Looper 
paper is the natural tendency for design engineers to ‘take the path of least resistance’ when 
faced with the inherent constraints that accompany commonality rules. While individual 
exceptions seem insignificant, it is often the case that an entire program diverges from 
commonality driven by the program manager’s responsibility to stay on cost and schedule. 

The Ground Systems Architecture Working Group is a partnership of international developers 
and operators of scientific and commercial satellites. The primary goal of the working group is 
to share lessons learned regarding the development of software systems used to manufacture and 
operate satellites. The eleventh working group meeting conducted in 2007 was devoted to 
addressing the issues associated with the increasing standardization and commonality of ground 
systems (software) to reduce overall lifecycle costs. Challenges reported with achieving 
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software commonality and new standards to increase interoperability were reported by Nadel 50 . 
The development of common software and new standards were shown to in fact reduce costs. 
However, several of the participants complained those benefiting most were follow-on programs 
and not the programs that originally funded the efforts thus limiting many program managers 
willingness to participate. Vendors complained that forcing commonality of software removes a 
competitive advantage that their proprietary solutions offer. Furthermore, vendors argued that 
clear business cases must be proven prior to investing in the development of new products based 
on new standards. Organizations such as CCSDS, ANSI, ISO, AIAA, and several government 
space agencies are contributing to the proliferation of numerous standards for space systems 
leading to confusion among software vendors as to which standards to support. Life cycles for 
satellite systems often exceed 12 years forcing new standards to provide some forms of 
backward compatibility to support legacy systems. The participants at the workshop also 
commented on the need for metrics to measure the benefits of commonality and standardization 
in order to convince management to support these efforts. 

3.5 Literature Review Summary 

Commonality for spacecraft systems is focused almost entirely on flight hardware with the 
objective of optimizing the number of spares to reduce mass, reduce volume and increase and 
probability of mission success. Very few papers were found that specifically address 
commonality as applied to ground systems and none were found that specifically address 
commonality of ground systems at launch sites. The emphasis in literature with respect to 
ground systems is on software re-use in command, control and data distribution systems for 
satellites and in one case, an element of the international space station. There is no mention of 
other ground systems commonality for mechanical systems such as transportation and handling 
equipment, avionics test equipment or propellant servicing equipment. The gap in literature 
suggests several opportunities to study the application of commonality at the launch site in 
previous and current space flight programs. 
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4 Commonality Assessment Framework 


In this chapter, a Commonality Assessment Framework is presented to compare the application 
of commonality across human spaceflight programs at KSC including Apollo, Space Shuttle, 
International Space Station and the early phases of Constellation. 

The Launch Services Program is also located at KSC. As the name of the program implies, it 
purchases a ‘service’ specifically to deliver a satellite to a particular orbit or interplanetary 
trajectory via launch vehicles such as the Atlas V, Delta IV, Pegasus, etc. The program does not 
purchase or assume ownership of launch vehicle hardware and is not responsible for developing 
spacecraft ground systems. It does maintain a real-time data monitoring and distribution systems 
that provides the capability to monitor the status of the launch vehicle and spacecraft for all 
missions with very few changes. Ground Systems used to support the Launch Services Program 
are not addressed in this paper. 

The areas addressed by the framework are listed below: 

• Management and Planning 

o Policy 
o Process 
o Timing 
o Contracts 
o Organization 

• Levels of Commonality 

o Between programs 
o Between projects 
o Between elements within projects 
o Between subsystems within elements 

• Types of Commonality 

o Operational 
o Technology 
o Design 

4.1 Management and Planning 

An important component of a successful effort to apply commonality is timely program and 
project management support. Program and project leadership establish expectations through 
policy and processes. Key questions regarding management and planning are listed below. Sub 
bullets are valid responses. 

• Policy: Was commonality required by the program and/or projects? 

o Yes - Commonality Documents were found 
o No - Commonality Documents not found 

• Process: Was there a specific process developed to govern and/or assess commonality? 

o Yes: Documented processes were found 
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o No: No document processes were found 

• Timing: If commonality was required, when was the policy imposed relative to the 
program/project lifecycle? 

o Program Formulation 
o Project Requirements 
o Project Design 
o Project Implementation 

• Contracts: Was language contained in the contract to support commonality initiatives or 
comply with KSC design standards (key enabler for commonality between flight and 
ground system projects)? 

o Yes - Language was found in contracts 
o No-No Language was not found in contracts 

• Organization: Did the structure of the development organization promote or hinder 
commonality? 

o Promote 
o Hinder 

In order fully recognize the effects policy, process and timing play on the implementation of 
commonality at KSC, it is important to understand the nature of NASA ‘programs’, how 
‘programs’ decompose into ‘projects’, and the typical NASA program/project lifecycle. 
Complete definitions and additional details are contained in NPR 7120.5D NASA Space Flight 
Program and Project Management Requirements and the NASA System Engineering Handbook 
NASA/SP-2007-6105 Revl. A ‘tailored’ view of the NASA program/project lifecycle from the 
perspective of the launch site is also provided. 

• Program: NPR 71205. D defines multiple types of programs: tightly coupled (e.g. Space 
Shuttle); single-project programs (James Webb Space Telescope); loosely coupled 
programs (e.g. Mars Exploration Program) and Uncouple Programs (e.g Discovery 
Program). Human spaceflight programs are tightly coupled and are composed of 
multiple projects that perform a single or multiple missions. The mission or missions can 
not be completed by any single project. Apollo, Space Shuttle, International Space 
Station and Constellation are all examples of tightly coupled programs. Projects within 
the Program are often managed at the center level. Programs typically last several years 
or even decades costing hundred of millions to tens of billions of dollars. The number of 
government and contractor personnel involved in Programs often exceeds several 
thousand. 

• Project: Delivers a specific capability to support missions defined by the program. 
Projects have their own requirements, lifecycle, budget, schedule, etc. Examples of 
projects with the Constellation Program include Orion (Crew Exploration Vehicle), Ares 
(Crew Launch Vehicle), Ground Operations and Mission Operations. DDTE for major 
project elements such as the Constellation Crew Exploration Vehicle typically are 
planned to last 5-10 years and costing hundred of millions to several billion of dollars. 
Number of government and contractor personnel involved in projects often exceeds 
several hundred. The first phase of the Constellation program is called ‘Initial 
Capability’ includes the development of the Ares I Crew Launch Vehicle, Orion Crew 
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Exploration Vehicle, EVA Systems and Ground Systems to support crew transport to and 
from the International Space Station. 

Program and Project lifecycles are divided into two phases; formulation and implementation. As 
shown by Figure 48, both periods are further decomposed into sub-phases. During formulation, 
concept studies are performed to establish mission goals and objectives and high level 
architecture. The architecture typically determines how to decompose the Program into projects. 
Program requirements are allocated to the projects followed by initiating the design process. 
Technology gap assessments are also performed based on design concepts at the project level. 
Discrete technology development projects are initiated and completed during this phase to allow 
insertion into detailed designs that occur later in the project lifecycle. For projects, the 
formulation phase typically ends at Preliminary Design (PDR). The Approval milestone shown 
in the lifecycle Figures signifies that the project has achieved the necessary design maturity to 
proceed to implementation within acceptable risk levels for technical, cost and budget. A 
Program typically will not proceed past formulation until at least one project is ready to enter the 
implementation phase. 

Implementation begins with phase D and includes system, subsystem and component detailed 
design is completed followed fabrication, system assembly, integration and test. According to 
the project lifecycle model. Phase D ends with launch and the Operation and Sustainment Phase 
E begins. The lifecycle ends with program/project closeout in Phase F. 
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Critical Design Review 

PLAR 
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Figure 48: NASA Program Life Cycle 51 
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From a ground operations perspective at the launch site, the operations phase begins as soon as 
the first flight hardware elements arrive at the launch site and continues through the final launch 
of the Program. An alternate view of the project lifecycle is shown below. 
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Figure 50: Alternate View of Program/Project Lifecycle 

During program formulation, leadership positions are filled such as the program manager, 
systems engineering and integration manager, project controls manager, etc. As the architecture 
is matured and project elements are identified, project mangers are named and project 
organizations are stood up to further refine the architecture and assist in developing the system- 
level requirements. In addition to architecture studies, key policy decisions are made during the 
program formulation phase shown by gray box ‘ 1’ in Figure 50. Policy decisions are included in 
program-wide plans such as the Systems Engineering Management Plan, Program Requirements 
Engineering Management Plan, etc. The decision as to whether or not to apply program-wide 
commonality is also made during this period. Following the initial program formulation phase, 
the projects begin development concurrently by writing their respective concept operations and 
requirements. Policy decisions regarding commonality at the project-level are made early in the 
development cycle (gray box 2). Depending on the acquisition strategy for a particular project, a 
single (‘prime’) contract or multiple contracts may be awarded develop flight hardware and 
ground systems. It is important to note that contract award may occur before or after of project- 
level requirements are base-lined. Depending on policy decisions made at the program and 
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project levels, commonality may or may not be considered during design (grey box 3). Near the 
end of the DDTE phase, the first sets of flight hardware are delivered to KSC for ground 
processing and launch. For Constellation, test flights are planned for Ares I and Orion prior to 
declaring the system operational. To simplify the drawing in Figure 50, only one launch is 
shown. 

Another management and planning factor affecting the application of commonality are contracts 
awarded to develop the flight hardware. The contract language should require and incentivize 
the contractor to support any programmatic policy effort including commonality. Commonality 
policy decisions made after contract award may require contract changes at additional cost to the 
program. As with most large aerospace programs, budgets are usually constrained making 
changes following contract award more difficult. 

The design of the development organization also may have an effect on the application of 
commonality. Often, communication within a development organization has significant effects 
on the ‘general approach’ used to design and develop complex systems. The communication in 
effect results in the establishment of informal policy used by multiple developers designing 
different systems. Subsystems developed within a tight project environment with little 
communication with other projects may result in diverse designs for similar equipment reducing 
commonality. 

4.2 Levels of Commonality 

Commonality levels describe the ‘breadth’ of its application across program and project 
boundaries and within individual projects. The fours levels of commonality studied are between 
programs; between projects; between elements; and between subsystems within elements. 
Examples of the four levels of commonality are given below. 

• Between programs: Shuttle and Constellation 

• Between projects: Ground Operations Project and Orion Project 

• Between elements within projects: Ground Operations Mobile Launcher Element and 
Launch Pad Element 

• Between subsystems within elements: Common operating systems across work stations. 

4.3 Type of Commonality 

For the ground systems assessment, a subset of commonality types defined by Hofstetter et al 
will be used: 

• Operational: Similar operational procedures used to perform the same internal functions. 

o Fueling operations, transportation and handling 
o Lifting operations 

• Technology: Objects leveraging off same technology used in different stages of ground 
processing 

o Fluid Systems 
o Command and Control Systems 
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• Design: Engineering designs are reused to create more than one instantiation of the 
object 

o J2X engines planned for use on both the Ares I and Ares V launch vehicles 
o Common parts used in ground systems 

The following types of commonality defined by Hofstetter er al will not be specifically 
studied. 

• Reusability: Objects are re-sued to perform multiple missions 

• Functional: Two objects perform same function internal and external function with 
different form 

• Multi-functionality: Same Object used to perform distinctly different functions 

The differences between the four programs studied with respect to reusability and functionality 
were determined to be negligible. This is certainly not to imply a relative lack of importance. 
Reusability is inherent in the design of ground systems at the launch site. They are designed to 
support multiple missions in many cases, and different phases of ground processing. For 
example, the Shuttle Mobile Launch Platform is used for integrated vehicle operations in VAB 
and launch operations at the Pad. Thus reusability is essential property of ground systems given 
the high replacement costs ground systems. Significant examples of mutli-functionality were not 
observed in any of the four programs. 
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5 Application of Commonality at the Launch Site 

As previously stated in Chapter 3, the literature review did not yield any specific papers 
regarding commonality at the launch site. Information regarding the degree to which 
commonality was applied during the Apollo, Shuttle and ISS programs at KSC is largely 
unknown and unpublished. The purpose of this chapter is to capture what was or was not done 
by providing specific examples of commonality and processes used to achieve commonality 
when available. 

Research Approach 

• Historical documents including letters, photographs and presentations were retrieved 
from NASA archives and existing program data bases 

• Walk-downs of facilities and high level inspections of ground systems were performed 

• Discussions were conducted with over 30 subject-matter experts involved with the 
development and operation of facilities and ground systems at the KSC during Apollo, 
Shuttle, Space Station Freedom, ISS and Constellation Programs. The subject matter 
experts contacted for this chapter are listed in the acknowledgements of this paper. 

5.1 Apollo Program 

The development of the Saturn V launch vehicle and the Apollo spacecraft was arguably one of 
the most ambitious programs of the 20 th century. Comparatively speaking, program and project 
management techniques of the time were still immature compared to current best practices. Very 
little information was found regarding program and project management policy with respect to 
the launch site. No specific policies regarding commonality were found in searches of KSC 
archives and nor in discussions with personnel involved in the actual development of the ground 
systems. However, engineers working at KSC did recall many problems with the significant 
amount of GSE early in the Apollo Program. The number of total GSE and support equipment at 
KSC for the Spacecraft and launch vehicle was over 34,000 items 53 . This issue was also noted 
by Tom Kelly, the Grumman Apollo Lunar Module Project Engineer, in his book Moon Lander: 
How we developed the Apollo Lunar Module . As early as the proposal evaluations in 1962, 
NASA severely criticized Grumman’s plan for Ground Support Equipment (GSE) as “poorly 
conceived, grossly under estimated”. Kelly later remarked in 1965: 

... the estimated number of required drawings increased by 100s a week. ...biggest 
unknown was for ground support equipment. ... Tome the GSE looked like a bottomless 
pit which we were becoming hopelessly mired. 

Beginning in 1965 the estimate for engineering drawings for the Lunar Module grew from a few 
thousand to over 50 thousand (more than 10 thousand were for GSE) 54 . By mid-way into the 
Lunar Module Project, hundreds of GSE items were identified. A recent 2006 historical study of 
Lunar Module processing at KSC identified dozens of unique specialized test and check-out 
equipment elements (rendezvous radar, landing radar, pyrotechnics, helium-hydrogen mass 
spectrometer leak detectors, etc.); 28 types of servicing equipment (RCS oxidizer servicing unit, 
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oxidizer transfer and conditioning units); and greater than 20 types of Handling Equipment and 
Fixtures (polarity fixture, transporters, slings, work stands, etc.) 55 . With schedule concerns 
mounting, a review led by Wesley Hjomevik implied the use of commonality to address these 
problems and recommended the following: 

...Grumman off-load its internal GSE workload by purchasing GSE end items from 
companies such as General Electric, North American, and McDonnell, which were 
already producing similar GSE units for the Apollo and Gemini programs that could be 
redesigned or modified for LM' 6 . 

Due largely to problems reported by both Apollo spacecraft manufactures, the program decided 
that ground support equipment (GSE) would be standardized as much as possible across the 
program, with common units supporting both the CSM and LM. The responsibility for GSE and 
site readiness was assigned to an organization within the Apollo Spacecraft Program Office. 

This organization exercised GSE management control over the two prime spacecraft contractors. 
The GSE provided the capability for vehicle test and checkout at the factories, development 
centers, and launch sites; ensuring operationally ready facilities and support equipment for each 
site/facility/vehicle combination. The GSE systems were designed to support similar vehicle test 
requirements and procedures at the various checkout facilities and thus provided the capability to 
obtain a close correlation of test data and to interchange GSE units among facilities. Ground 
support equipment end-item design was standardized to reduce the number of different units; the 
GSE manufacturing time; and GSE test time. This type if GSE was referred to as ‘Common Use 
Equipment’ and was divided into three categories: 

• Category A-l: Equipment was unmodified hardware that fulfilled the requirements of 
more than one contractor. The developing contractor operated the hardware and 
maintained configuration control. 

• Category A-2: Equipment was the same as category A-l equipment except that the using 
contractor operated it. Modifications were fabricated by the developing contractor and 
installed by the user. 

• Category A-3: Equipment designed for multiple applications. Modifications to the 
original designs were necessary for specific uses. The using contractor had total 
responsibility for the hardware 57 . 

Standardization of the GSE allowed a reduction in the number of spare parts required and in the 
operating personnel training requirements. Furthermore, the GSE system-standardization 
approach permitted maximum use of GSE units among checkout facilities and assisted in 
meeting the Apollo schedules 58 . Thus, there is some evidence of a program policy and project- 
level commonality between Command Service Module and Lunar Module projects. There is 
also evidence of several types of commonality with GSE including operational, technology, 
design and reusability given that duplicate sets of GSE were used to support the two spacecraft. 

A prime example of the application of commonality was Automated Check-out Equipment 
(ACE). During the check-out and launch operations of the Mercury spacecraft, approximately 
100 measurements were monitored via telemetry. As early as 1961, the number of 
measurements required for the Apollo spacecraft were predicted to be over 2000. Manually 
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monitoring every measurement during critical tests was simply not feasible. Engineers from the 
Preflight Operations Division at the launch site proposed the development of ‘Automated Check- 
out Equipment’ based on the latest computers available at the time. ACE was to be developed by 
the General Electric, the Apollo Integration Contractor. The proposal went all the way to NASA 
headquarters and was approved over the objections the CSM prime contractor (North American 
Aviation) who planned to develop their own systems 59 . 

ACE provided the capability for automatic, semiautomatic, or manually controlled prelaunch 
testing of the Apollo Command and Service Modules (CSM) and Lunar Module (LM). It could 
produce test commands and stimuli, monitoring spacecraft subsystem performance, conversion 
and processing of data, measurement of subsystem responses to test stimuli, diagnostic testing, 
and enabling communication between the spacecraft and engineering personnel. The ACE 
consisted of a Ground Station, Carry-On Equipment, and Peripheral Equipment. The Carry-on 
equipment (literally brought on-board the spacecraft) provided the special interfaces required to 
communicate to unique CSM and LM subsystems. The Peripheral Equipment allowed the 
Ground Station to communicate to the CSM and LM GSE 60 . A total of 14 ACE Ground Stations 
were installed in factory facilities at North American Aviation plant in Downey, CA, the 
Grumman plant in Bethpage, NY, Manned Spacecraft Center (renamed the Johnson Space 
Center in 1973) in Houston and at KSC 61 . 



Figure 51: Astronauts and Ground Ops Crew in ACE Control Room in the O&C [NASA] 
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The Automated Check-out Equipment (ACE) is one of the best examples of commonality 
between elements within the Ground Operations at KSC, as well as between projects within the 
Apollo Program. It was used to support factory test, offline spacecraft operations, integrated 
operations in the VAB and pre-launch operations at the launch pad. Thus multiple commonality 
types were exhibited including between projects (CSM/LM and Ground Operations) and 
between elements within a project (off-line ground operations and integrated operations). 

One key enabler was existence of the Integration Contractor. Apollo required the coordination 
of dozens of contractors and government agencies. NASA headquarters recognized this issue 
early in the program and proposed the addition of a new integration contractor. The idea was 
almost universally rejected by the prime contractors who opposed having competitors oversee 
their own work as well as the centers (including KSC) who believed the integration contractor’s 
responsibilities overlapped with their own. General Electric was ultimately hired in 1962 and 
performed three functions: develop check-out equipment for launch operations (ACE), assess 
launch vehicle and spacecraft reliability and to performed an integration role 62 . Relative to the 
overall program/project lifecycle, the decision to hire the integration contractor and use ACE 
occurred after the prime contracts were awarded to North American Aviation, Grumman, 
Boeing, Chrysler, etc. Without the leadership demonstrated by the Washington-based program 
management team, it is unlikely that benefits having essentially only one check-out system for 
the spacecraft would have been realized. 

Despite the efforts to standardize GSE noted by Kelly and Jenkins et al, personnel at KSC 
involved in Apollo Ground Operations recalled multiple instances where GSE designed by the 
spacecraft OEM simply did not function at KSC. Examples include fluid servicing carts and 
special electronics test equipment. Problems were attributed to the unique environment at KSC 
such as frequent lightning storms; power surges; corrosive salt air environment; and unusual 
servicing configurations such as having to pump commodities up several hundred feet from the 
base of the mobile launcher to the spacecraft. In many cases, problematic GSE provide by the 
OEM had to be discarded and replaced by systems development at the launch site thus limiting 
the commonality benefit. 

Organizational issues were also noted as a contributing factor to the lack of commonality at the 
launch site. Access and services to the Saturn V and Apollo Spacecraft were provided by nine 
swing arms attached to the launch umbilical tower. The swing arms were attached to the Apollo 
Launch Umbilical Tower and initially, were treated as discrete projects. Personnel representing 
each engineering discipline reported directly to each swing arm project manager. Each swing 
arm project had its own structures engineer, fluids engineer, electrical engineer, etc. As the 
design for the swing arms progressed, personnel at the launch site who ultimately would have to 
operate and maintain the swing arms noted significant differences in the design and parts used 
for each arm. The lack of commonality between the swing arms was attributed to the lack of 
communication between engineering personnel in the same discipline working on different 
projects. In the case of swing arm design, one engineer recalled the following: 

The Launcher Accessories groups were organized on a product basis - Hold down Arms, 

Swing Arms, Tail Service Masts, etc. As such, each group was self-sufficient with 

electrical and mechanical engineers together in each group. Imagine how commonality 
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was attained with this organization. There was none. As such, there were no common 
electrical design rules, components, parts, or documentation seen in the designs. This 
was soon changed by encouragement from the launch operations engineers as the 
differences in design approach, documentation and components were difficult to contend 
with at the launch site. We Op's folks finally convinced the manager of the Launcher 
Accessories Group to become skill-oriented instead of product-oriented and we began 
seeing commonality of documentation, parts and components and common logic within 
the designs. It did not happen overnight. 

An Electrical Systems Branch was formed and needed specifications and standards were 
written that included the “what” as well as the “how" in order to establish a common 
design approach. MSEC had a well organized components group that acquired, tested 
and specified electrical components and parts for use in ground support and servicing 
equipment that both MSFC and KSC then used. These items included relays, power 
contactors, wire, cable, connectors, fasteners, chassis slides, and a packaging standard 
that provided selected sizes for front panels, rear chassis sizes and console/panel colors. 

The problems with lack of commonality with parts and designs at the launch site eventually led 
to formal KSC Specifications and Standards for Design and Fabrication of Ground Support 
Equipment used for subsequent programs. 

It is also important to note the reuse of existing infrastructure. In addition to proximity to the 
south east coast of the United States, some of the primary reasons for locating the Apollo Launch 
Systems on the lands to the north and west of Cape Canaveral Air Force Station were the 
availability of existing infrastructure such as roads, bridges, airports, seaports, railways and 
existing range tracking and communications systems. The following table summarizes 
commonalty findings for ground systems developed for the Apollo Program. 
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Table 3: Apollo Ground Systems Commonality Summary 


Apollo Ground Systems Commonality Summary 

Management and Planning 

Program Wide 
Policy 

No 

No policy documents were found. However, decision to use ACE at 
spacecraft manufacturing facilities, KSC and JSC required a programmatic 
directive. 

Project Wide 
Policy 

No 

No ground operations policy documents were found. Discussions with 
personnel who developed ground systems at KSC did not remember any 
specific policy directives. 

Timing 

Project 

Design 

Decision to use ACE was made following CSM and LM contract awards. 

Contracts 

No 

Problems with LM GSE and subsequent push to leverage of CSM GSE 
implied potential scope changes in Grumman LM project. No actual 
contractual documents were located indicating changes. 

Organization 

Hindered 

Each Swing Arm on the Launch Umbilical Tower was designed by a 
different organization resulting in a large diversity of designs and parts. 

Levels of Commonality 

Between Programs 

Yes 

In terms of infrastructure, range assets as well as roads, rail ways, runways, 
etc were reused. However, from a purely ground systems perspective, no 
evidence of commonality between programs was found. All ground 
systems including Facilities, GSE and SE were developed specifically for 
Apollo. 

Between Projects 

Yes 

ACE was the best example of Ground Systems used between projects 
(Ground Operations, Mission Operations, Command/Service Module, and 
Lunar Module). A number of specific items of GSE were identified in 
recent Apollo spacecraft whitepapers. However, it could not be determined 
with certainty if the same GSE or GSE design was used between the CSM 
and LM or for offline operations between the different stages on the Saturn 
V. 

Between Elements 
within Ground 
Operations Project 

Yes 

Design documentation required to perform this level of assessment was not 
available. However, it can be argued that the Mobile Launch 
Platform/Launch Umbilical Tower and Crawler Transporter are examples 
of commonality between elements (Integrated Operations Ground Systems 
and Launch Operations Ground Systems). 

Between 

Subsystems within 
Ground System 
Elements 

Indetermin 

ate 

Design documentation required to perform this level of assessment was not 
available. 

Types of Commonality 

Operational 

Yes 

While the specific test procedures for CSM and LM check-out were 
different, the user interface to ACE was essentially the same allowing 
workers to support the check-out of types of spacecraft. 

Technology 

Yes 

Establishment of electrical common parts for use in multiple GSE 
systems. 

Design 

Indetermin 

ate 

It is believed that this type of commonality did exist. However, design 
documentation required to perform this level of assessment was not 
available. 
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5.2 Space Shuttle Program 


The desire to reduce the costs of space transportation was probably the most important factor 
leading to the development of the Space Shuttle. In 1969, President Nixon’s Space Task Group 
indentified the need to lower the cost of space transportation in order to allow frequent servicing 
of a new orbiting space station: 

Exploration and exploitation of space is costly with our current generation of expendable 
launch vehicles and spacecraft systems. This is particularly true for the manned flight 
program. Recovery and launch costs will become an even more significant factor when 
multiple re-visit and resupply missions to on Earth orbiting space station are 
contemplated. Future developments should emphasize: 

Commonality - the use of a few major systems for a wide variety of missions. 

Reusability - the use of the same system over a long period for a number of missions. 

Economy - far example, the reduction in the number of "throw away" elements in any 
mission; the reduction in the number of new developments required; the development of 
new program principles that capitalize on such capabilities as man-tending of space 
facilities; and the commitment to simplification of space hardware. 

Later in the report, the Space Task Group specifically recommended the following: 

...develop new systems and technology for space operations with emphasis upon the 
critical factors of: (1) commonality, (2) reusability, and (3) economy, through a program 
directed initially toward development of a new space transportation capability and space 
station modules which utilize this new capability 63 . 

Thus, prior to the formal approval of the Space Shuttle Program in 1970, the value of 
commonality was established at the highest levels. Concepts for the development of the ground 
systems began immediately. 

Eager to meet the critical objectives outlined the Space Task Group; KSC suggested the 
development of a common control system for use across the Shuttle Program. While the Apollo 
ACE system was indeed an excellent example of commonality used program-wide for factory 
and offline spacecraft checkout, there were still a total of three unique control systems developed 
for use at each of the manned spaceflight centers (KSC, JSC and MSFC). In a letter written in 
1970 by KSC Center Director Kurt Debus to Associate Administrator Dale Myers, Debus 
attributed the development of three systems to the following: 

KSC ’s role in ground support equipment and flight hardware design has been primarily 
that of a consultant, providing inputs to the development centers [JSC and MSFC], As a 
result, two problems have occurred: first, hardware design has not sufficiently 
recognized the operational requirements of assembly, check-out and launch; and second, 
all three MSF Centers have developed separate checkout and data systems, with 
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subsequent duplication of hardware. ... The Space Task Group used the key words of 
commonality, reusability, and economy. These words should apply to ground systems 

also . 64 

Debus expanded his proposal to include the development of all GSE to be used at the launch site 
in a follow-up letter to Meyers in 1971. He proposed to produce a total systems concept at 
minimum cost. This will include integration of the ground systems and equipment, maximize 
commonality and reusability’ 65 . The benefits of commonalty were recognized early in the Shuttle 
Program at the launch site by KSC senior management. 

In an early report written in 1971 on requirements for ground support and facility requirements, 
processing flows were developed for both horizontal and vertical take-off versions of the Shuttle 
as shown below in Figure 52. At the time of this report, the final configuration of the Space 
Shuttle System was not yet established. The report refers to two vehicles: a reusable liquid 
flyback booster and orbiter. The final configuration of the Space Shuttle eventually evolved to 
the orbiter, external tank and twin solid rocket boosters. 



FIGURE 4 GENERALIZED FLO* FOR FINAL ASSEaBLT AMD FLIGHT TESTING 


Figure 52: Early Shuttle Ground Processing Flow Concept 66 


The processing flows were used to perform a systematic assessment of the ground systems 
required to process the Shuttle at the launch site. An example from the report is shown below: 
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Figure 53: Early Shuttle Ground Systems Assessment 67 

The report concluded with a number of recommendations for the further definition of ground 
systems including seeking maximum commonality between orbiter and booster GSE and to 
include commonality requirements in ground system specifications. 

The assessment of commonalty requirements for GSE was also one of five steps included in an 
early proposal for the Shuttle Launch and Landing Ground Systems Acquisition Plan. Three of 
six Ground Systems were identified by the proposal as common both to the factory and the 
launch site: vendor Line Replaceable Unit (LRU) maintenance equipment; development 
contractor LRU and systems maintenance equipment; and common factory launch site 
equipment. It was recognized that not all capabilities required at the factory were needed at the 
launch site and that equipment destined to be used primarily at the launch site be optimized for 
the launch site environment. A number of additional documents located in the KSC archives 
clearly indicate a strong desire at the earliest stages of the Shuttle Program to utilize 
commonality to reduce costs at the launch site. 

In 1973, the Orbiter Project Manager, Aaron Cohen, assigned responsibility of launch site GSE 
developed by Rockwell International Corporation to KSC. This in part realized Debus’ goal of 
allowing KSC to more directly manage the development of ground systems destined for use at 
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KSC. This new authority allowed requirements unique to the KSC environment to be accounted 
for early in the development process of GSE. 

The Space Shuttle Main Engines (SSME) were arguably one of the most complex and 
challenging technology development area in the Shuttle Program. The Main Propulsion Test 
Article (MPT A) was designed to test the Shuttle Main Engines. It consisted of all the cryogenic 
plumbing and electrical systems contained in the aft section of the Space Shuttle as well as non- 
flight Shuttle External Tank. Early in the planning for the MPTA, it was recognized that ground 
systems planned for KSC to control and monitor loading of the External Tank and operation of 
the SSMEs could be used at the Stennis Space Center as recalled by one engineer below: 

During the Saturn/Apollo period the ground support systems were designed, built, 
installed and operated by the organization at that Center or location, e.g., Saturn SIV & 
SIVB was accomplished by Douglas Aircraft for all locations where the stage was to be 
serviced, Rockwell did the same for the Saturn SII stage, and MSFC provided for the 
Saturn SIC at Huntsville and again for SSC (then called MTF). This included the GSE 
but not the facility for the KSC locations. Our experience was not good with this 
approach which resulted in schedule delays, flight hardware damage when trying to 
service the first time, and of-course added cost to the program. 

Because of the lesson learned from the above experience, the Shuttle Program accepted 
our recommendation to have KSC design the Shuttle vehicle MPS propellant and gases 
loading GSE for both KSC and the off site development site (MPTA @ SSC). This 
approach worked very well and saved considerable cost by deleting a dedicated facility 
at KSC required to activate the launch site (A dedicated facility vehicle was required to 
activate the launch site for the Saturn V). There was only one design required and 
considerable testing was accomplished at SSC developing the operational procedures 
and refining the design for maintaining the propellant in the flight tanks at the desired 
level for launch. If technical problems were encountered during the development testing 
at a location other than KSC, the resultant impact is less to the schedule ... 

One important realization resulting from the development of ground systems for Apollo was the 
need for design standards at KSC. As was stated previously, personnel supporting ground 
operations during Apollo recalled several instances where GSE manufactured by the spacecraft 
OEM simply did not work in the unique operating environment of KSC. To address this, the 
first design standards emerged in 1970 as GP-863 General Criteria for Design of New 
Equipment and Facilities to be Utilized at KSC. In 1 974, the Shuttle Program also released the 
first version of SW-E-0002, Space Shuttle GSE General Design Requirements. GP-863 later 
replaced in 1983 with KSC-DE-512-SM, Facility, Systems and Equipment General Design 
Criteria. The document applied to design of facilities and ground based hardware and software 
used to support transporting, receiving, handling, assembly, test, check-out, service, and launch 
of space vehicles and payloads at launch, landing and retrieval sites. The document evolved over 
the years and the latest revision was released in 2004. It is comprehensive and addresses a wide- 
range of safety and design considerations from structural design margins to fungus resistance. 

The document includes specific design requirements as well as referencing a broad range of KSC 
unique, military and commercial design standards. 
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The KSC and Shuttle Program specifications together guided the development Facilities, GSE 
and SE. The emergence of these standards facilitated commonality through parts standardization 
and ensuring equipment intended to operate at the factory and at the launch site did not have to 
be redesigned due to the lack of understanding of the KSC environment. A good example of this 
is fluid and gas control panels located throughout the center. Each panel is designed in 
accordance to the design standards. At the lowest level, commonality was achieved at the parts 
level, reducing the logistics foot print required for spares and simplifying sustaining engineering 
requirements. The standards also ensured commonality with respect to the operator interface. 
The familiar look and feel of each panel enabled certain level of operations commonality 
reducing procedure development as wells as reducing operator errors. 

Leveraging off the positive experience with the Apollo ACE system, proposals were made early 
in the Shuttle Program to develop a single command and control system for use KSC and JSC. 
KSC proposed the Launch Processing System (Chapter 2) and JSC proposed a system called 
Universal Test Equipment (UTE). There was considerable debate as well as sense of 
competition between the two proposals as one engineer involved in the early negotiations 
recalled: 

JSC proposed a new system called UTE - Universal Test Equipment. Their “MCC ” at 
the time was communication gear and meters. As I remember, the UTE was more of a 
lab control environment without the speed needed by LPS. There was little redundancy 
capability and limited user friendliness. There were big shootouts resulting in a 
management summit at JSC where the program gave KSC the go ahead for LPS. There 
was an ongoing race between JSC and KSC to decide who will provide the Space Shuttle 
ground systems for use at KSC. We pitched LPS to Bob Thompson and JSC pitched UTE. 
They also countered with Super UTE. Bob Thompson, Shuttle PM, decided that KSC has 
the launch and landing job and they should prevail. 

Several LPS sets were ultimately built to support operations in the Shuttle ground processing in 
the OPFs, VAB, Pads and at the HMF. A set to test LPS system software and application 
software with Orbiter avionics was also deployed at JSC in the Shuttle Avionics Integration 
Laboratory. Early in the Shuttle Program, LPS sets were also installed at MSFC and later in the 
VAB to support offline SRB operations (AFT Skirt and Forward Skirt and Frustum 
refurbishment). The LPS sets at MSFC and in the VAB were decommissioned relatively early in 
the program and replaced with smaller and more flexible systems. 

One engineer who was involved with the development of Shuttle Ground Systems also noted the 
effects vehicle architecture on commonality. Electrical, fluid and gas interfaces with a fully 
stacked Apollo-Satum V launch vehicle required nine separate swing arms. As stated earlier in 
the chapter, this architecture contributed to the propagation of different GSE designs. The 
primary interfaces for these same services on the Space Shuttle are via two Tail Service Masts 
(TSMs) and a rise-off umbilical for each SRB located on the Mobile Launch Pad. The TSMs 
interfaces directly to the Obiter as shown in Figure 54 below. From a ground systems 
perspective, the Orbiter served to integrate the requirements for ground services for all three 
elements subsequently reducing the number of ground systems interfacing to the vehicle during 
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integrated operations in the VAB and at the Pad. This type architecture also drove the need for a 
strong systems engineering effort early in the program to ensure the ground servicing 
requirements for the ET, SRB and Orbiter were all satisfied via the same two TSMs. 



Figure 54: One of Two Shuttle Tail Service Masts [NASA] 

Note: Prior to the Challenger accident, SRB ground interfaces consisted of a single nitrogen 
purge line and COAX data interface that separated at T-0 with a simple rise-off umbilical. SRB 
joint heaters were added as part of a mitigation strategy to ensure nominal performance of the O- 
rings. The joint heaters required new ground power interfaces that were added to the rise-off 
umbilicals. 

Given the decision to perform launch and landing operations between KSC, commonality 
between programs for infrastructure and many major ground systems was an obvious choice. A 
table listing some of major facilities and ground systems reused from Apollo to Shuttle is shown 
Table 4. 
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Table 4: Apollo to Shuttle Ground Systems Re-use 


Apollo to Shuttle Ground Systems Re-use 


Ground System 

Comments 

Industrial Area Institutional Support 
Facilities and Infrastructure 

Headquarters Building, Central Instrumentation Facility, 
Occupational Health Facility, Training Auditorium, warehouses 
and numerous other smaller facilities were all reused. Supporting 
infrastructure such as roads, railways, sea ports, power distribution 
systems, water systems, etc were also reused. 

Operations and Check-out Building 
Astronaut Crew Quarters and High Bay 

ACE, and Test stands for CSM and LM were removed. High bay 
utilized for early Shuttle Cargo Processing including Hubble Space 
Telescope and Space Lab. 

Hypergolic Building and Fluid Test 
Complex 

Renamed Hypergolic Maintenance Facility. Re-outfitted to support 
maintenance and check-out of the Orbiter Forward Reaction 
Control System and Orbital Maneuvering System Pods 

Vehicle Assembly Building 

High Bays 1-3 were refitted with new moveable work platforms to 
support stacking of the Shuttle system including SRB stacking; ET 
Mate and Orbiter Mate integrated testing prior to roll-out to the 
launch pad. High Bays 2 and 4 were re-outfitted to support offline 
External Tank test and check-out. Early in the Shuttle Program, 
SRB Aft Skirt and, Forward Skirt and Frustum refurbishment 
occurred in the VAB Low Bay. 

Mobile Launch Platforms 

All three Apollo Mobile Launchers were modified to support 
Shuttle. The launcher base flame ducts were reconfigured to vent 
the SRB and SSME exhaust. The Launch Umbilical Towers were 
removed from the launcher base. The top section of the tower was 
used for the Shuttle Fixed Service Structures on Launch Pads 39 A 
and B. 

Crawler-T ransporter 

Both Crawler-Transporters were reused. No significant 
modifications were required to support Shuttle. 

Crawler Way 

Re-used with no significant modifications. 

Launch Control Center 

All equipment such as the RCA 1 1 OAs were removed from the 
firing rooms. The Shuttle Launch Processing Systems was 
installed on the second and third floors including in all four Firing 
Rooms. 

Launch Pads 39A and 39B 

Both pads were modified to support Shuttle Launch Operations. 

No substantial modifications were made to the launch pad concrete 
structure. The shape of the Flame Deflector mobile structure was 
modified in shape and fixed to flame trench. New Fixed Service 
Structure and Rotating Service Structures were erected on the Pad 
Service. Hydrogen and LOX dewars were reused from Apollo. 

Orbiter Processing Facilities 

New for Space Shuttle Program 

Assembly and Refurbishment Facility 

New for Space Shuttle Program 

Rotation, Processing and Surge Facility 

New for Space Shuttle Program 

Shuttle Landing Facility 

New for Space Shuttle Program 
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The significant level of reuse was enabled in large part by choosing the same overall ground 
operations approach as Apollo - the Mobile Launch concept. Substantial cost savings were 
realized early in the Program, allowing resources to be correctly applied to the Shuttle’s state-of- 
the-art technology development requirements. In general terms, commonality between the 
Apollo and Shuttle Programs was achieved primarily with facilities, structures, large mechanical 
systems and large fluid systems. All of the Apollo data acquisition and command and control 
systems were replaced by newer computing systems that were rapidly evolving at the time of 
Shuttle ground system development. It is interesting to note that reuse of the VAB and Launch 
Pad constrained the design of the Shuttle to some degree by the width of the VAB doors as well 
as the width of the flame trench. The following table summarizes commonalty findings for 
ground systems developed for the Space Shuttle Program. 
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Table 5: Space Shuttle Ground Systems Commonality Summary 


Space Shuttle Ground Systems Commonality Summary 

Management and Planning 

Program Wide Policy 

Yes 

Commonality was directed at the highest level by the Space Task Group 
chartered by President Nixon. 

Project Wide Policy 

Yes 

Emphasis on commonality appeared in several documents including 
letters written by KSC Center Director and reports by KSC project 
managers. 

Timing 

Program 

Formulation 

Direction to address commonality was given by the Space Task Group 
prior to Space Shuttle Program approval. Early efforts to develop ground 
systems concepts specifically included requirements to address 
commonality. 

Contracts 

Indirectly 

Addressed 

The flight hardware prime contracts were managed by JSC and MSFC. 
KSC was assigned the responsibility to oversee the design of launch site 
GSE developed by Rockwell International Corporation. Therefore, 
requirements unique to the launch site were addressed during 
development. 

Organization 

Promoted 

Personnel were matrixed to ground system projects from engineering 
teams organized by discipline facilitating common design for similar 
systems across ground system projects (i.e. Mobile Launch and Launch 
Pad). 

Levels of Commonality 

Between Programs 

Yes 

In terms of infrastructure, range assets as well as roads, rail ways, etc 
were reused. Major Ground Systems were reused between Apollo and 
Shuttle as described in Table 4. 

Between Projects 

Yes 

Commonality between GSE used in the factory and the launch site was 
directly addressed during development. KSC developed GSE used at the 
MPT A was a rare example of ground systems developed for use at the 
launch site actually used ‘upstream’ in the DDTE phase of a flight 
hardware system (SSME). 

Between Elements 
within Ground 
Operations Project 

Yes 

LPS Sets were deployed to multiple processing locations around the 
center to support offline operations in OPFs; Integrated Operations in the 
VAB; Launch Operations at the Pads; payload operations in the O&C 
then the SSPF and at the Shuttle Avionics Laboratory at JSC. Fluid 
System Panels were based on a common design and were in multiple 
locations around the center. 

Between Subsystems 
within Ground 
System Elements 

Yes 

Subsystems within command and control systems as well as fluid systems 
used common designs. 

Types of Commonality 

Operations 

Yes 

Shuttle payload processing. Similar operational procedures are used to 
test and check-out payloads prior to installation in Orbiter payload bay. 

Technology 

Yes 

Establishment of common parts for electrical and fluid systems for use 
in multiple ground systems. 

Design 

Yes 

Command and Control Systems and Fluid Systems 
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5.3 Space Station Freedom/International Space Station Program 

As discussed in Chapter 2, development of the Space Station began with the Freedom Program in 
1984. In 1986, the Space Station Freedom Program Office was established in Reston, Virginia to 
oversee the work of four NASA centers (Marshal Space Flight Center, Johnson Space Center, 
Lewis Research Center, and KSC) and five prime contractors (Boeing, McDonnell Douglas, 
Rocketdyne, Rockwell and Harris). The Lewis Research Center was renamed the Glenn 
Research Center in 1999. The organizational structure of the Freedom Program is shown below 
in Figure 55: 
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Figure 55: Space Station Freedom Program [NASA] 


Figure 55 illustrates the inherent complexity of managing the technical baseline of a program as 
large and as complex as Freedom. To address this, NASA competed and awarded a contract to 
the Grumman Corporation to perform program-level systems engineering and integration across 
all NASA Centers, prime contractors and international partners. Payload Ground Processing was 
assigned to KSC. 


Recognizing the potential to reduce both development and recurring life cycle costs, 
requirements for commonality were established early in the Program. In order to successfully 
implement commonality across such an organizationally diverse program, the Freedom Program 
instituted the Space Station Commonality Program (SSCP). In 1988, the Space Station 
Commonality Process Requirements was released that formally documented a program-wide 
approach for commonality. The document describes seven components of commonality: 
commonality within systems and equipment; commonality between systems and elements; 
commonalty between the Space Shuttle Program and other NASA Programs; approval of unique 
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items; use of standard parts; commonality within support equipment; commonality relative to the 
Software Support Environment . The plan defined commonality as follows: 

Commonality can be broadly defined as the use of identical, interchangeable, 
interoperable, functionally compatible (see the Glossary) or, at least, similar hardware, 
software, Support Equipment (SE), operating and training procedures, and technical 
design approaches across a program for satisfying different sets of functionally similar 

requirements. 

The SSCP was comprehensive and included both flight and ground systems. The scope of the 
program-level commonality plan includes hardware (specifications, parts, components, 
subsystems and systems including interface hardware), software (specifications, designs and end 
products), Support Equipment, facilities/fixtures, functions, processes, procedures, operations, 
test/verification, training, documentation, standards, and user interfaces (e.g., displays, 
ergonomics). Organizational roles and responsibilities from Level I (NASA HQ) through the 
Level 3 Station Work Packages were managed at the centers as shown in Figure 56. 



Figure 56: Space Station Commonality Program Roles and Responsibilities [NASA] 

Commonality between the National Space Transportation System (NSTS - now known simply as 
the Space Shuttle), international partners as well as the Level III Work Packages was coordinated 
by the Program at Level II. Figure 56 clear shows a closed-loop process between all stake 
holders to manage and track progress of the commonality program. The document specifically 
requires commonality: 

All SSP items shall be common unless approval has been granted to make the items 
unique, or unless waivers or deviations have been granted by the Systems Integration 
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Board (SIB)/SSCB. However, all potential commonality items shall undergo analysis 
using System Commonality Analysis Tool (SC A T 68 ) and/or other commonality analysis 

tools. 

Detailed processes were defined to ensure accountability across the Program for commonality. 
Processes included the search for common functions/items; evaluation of candidate unique items 
and common items and the population of program-wide databases. Each Level III organization 
was required to develop commonality plans to comply with the SSCP. While detailed design 
commonality analysis was the responsibility of the work package owners at Level III, approval 
for unique items and non-standard parts had to be approved at Level II by the Space Station 
Control Board as shown in Figure 57. 



Figure 57: Space Station Program Level Commonality Process [NASA] 


A number of companion documents also supported the commonality program. A partial list is 
shown below: 

• Space Station Systems Requirements (defined commonality requirements) 

• Space Station Ground Support Equipment Integration Process Requirements 

• Baseline Configuration Document (list of common items) 

• Space Station Approved Electrical, Electronic and Electromechanical Parts List 

Space Station Freedom Commonality efforts at KSC were guided by both Program Level 
Commonality Plan and the Space Station Ground Support Equipment Integration Process 
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Requirements. The first revision of the GSE Integration Process was released in 1986 and the 
last revision was released in October 1993. The KSC Program GSE Management Office was 
assigned by Level II to manage and integrate all Space Station Program GSE. In this role, the 
KSC developed and maintained the Support Equipment Data Base; led GSE trade studies and 
commonality analysis; recommend acquisition strategies; and provide program tracking and 
status of GSE. The System Engineering Flow Diagram for Support Equipment is shown in 
Figure 58. 
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Figure 58: Support Equipment System Engineering Flow [NASA] 


In the 1989, following several architectural design changes and diminishing support in Congress, 
changes were made to the Space Station Program management structure. A new program 
manager was assigned to lead the effort to address mounting cost and technical challenges. The 
new program manager de-emphasized commonality. One of the most significant changes to 
affect to the development of ground systems was the disbandment of Level II GSE Management 
Office at KSC. Responsibility for the development of GSE was pushed to the Level III Work 
Packages with little program-level involvement or coordination. Efforts to achieve some degree 
of commonality were now entirely the responsibility of the Level III projects. While the 
commonality plans remained ‘on-the books’, personnel involved with the Program recalled an 
immediate lack of management support at the Program level and noted distinct differences in the 
level of support for commonality between the four work package projects. 
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Problems with the Program continued in for the next three years and by 1993, Space Station 
Freedom was effectively cancelled. As part of larger effort to mitigate concerns over the 
proliferation of nuclear weapons technology following the collapse of the Soviet Union, 

President Clinton directed NASA to expand international partnership agreements to include 
Russia. The new Program was called International Space Station. A new space station design 
was developed that included Russian Service, Control, Docking and Multipurpose Research 
Modules. Russians also agreed to provide crew and cargo transport via Soyuz and Progress 
spacecraft. 

The Freedom Program office in Reston, Virginia was closed and Program management was 
moved back to JSC. The overall Freedom management and contract structure (Figure 55) was 
determined to be too complex and lacking in accountability. NASA decided to centralize all 
development work for US elements under a single prime contractor (Boeing). It was hoped that 
a single prime contractor would reduce integration problems and help control costs. It was 
during this period that the new program management embraced a philosophy known as ‘ship and 
shoot’. Spacecraft arrive at the launch site in a flight ready configuration. Only basic shipping 
and receiving inspections and minimal servicing are performed prior to installation into Orbiter’s 
payload bay. In order to reduce the costs, planned pre-launch testing at the KSC was essentially 
eliminated. No integration tests between the elements were planned at the launch site. From a 
ground systems perspective, this resulted in a dramatic de-scope of the amount of GSE expected 
to be required at the launch site. 

While the prime contractor was expected to perform some level of commonality analysis, those 
involved with the development of ground systems at the time felt a further de-emphasis of 
commonality. The original Freedom requirements documents and program plans including the 
commonality plans and the GSE integrations process developed for Freedom were abandoned at 
this time and new program level documents and were developed for ISS. No commonality 
processes were found within the new program documentation. Program management believed 
the reduction in planned pre-launch test and check-out would significantly limit the amount of 
GSE and little to no factory test equipment would be required at the launch site. KSC design 
standards include requirements for LOX compatibility, hazard proofing, corrosion protective 
coatings, high structural safety margins, safety assessments, etc. It was argued that KSC design 
standards unnecessarily increased costs of the development of factory test equipment. Therefore, 
the KSC design standards were not imposed on factory test equipment and the contractors were 
free to use their own standards in the manufacturing environment. 

By the mid-1990s, the development of both Russian US flight hardware elements began to fall 
behind schedule. The planned first launch of the first ISS element slipped from 1997 to 1998. 
Driven by increases in complexity of on-orbit assembly, the number of EVA hours required to 
assemble the station grew from approximately 800 hours to over 1 100 hours 69 . NASA addressed 
these concerns by planning a series of Multi-Element Integration Tests at KSC (Chapter 2) and 
by directing the contractor to ship several partially built elements to KSC in order to speed final 
manufacturing and assembly. 

The addition of MEITs and onsite manufacturing and assembly increased the amount of factory 
test equipment planned for use at KSC substantially. This presented a variety of challenges. 
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Several problems were already reported with the factory test equipment including leaks with 
ammonia servicing equipment and damage to Truss Elements by ground power supplies. The 
KSC design standards for Ground Systems contain the cumulative knowledge of years of 
experience developing facilities and systems to support operations at the launch site. Many of 
the requirements contained in the design standards are included to ensure the safety of workers 
and flight hardware. It was noted that problems with the ammonia servicing equipment at the 
factory likely would not have occurred if KSC design standards were followed by the Element 
contractor. The original Factory Test Equipment was discarded and a special unplanned vapor 
containment facility and additional ground systems were eventually constructed adjacent to the 
SSPF to support ammonia servicing operations. Problems were also reported with ground power 
supplies, load banks and simulators. 

Personnel familiar with the problems with Element factory test equipment were reluctant to 
allow the factory test equipment to be used at KSC without thorough engineering evaluations and 
safety assessments. To address these concerns, a risk-based process was established to regulate 
the use of factory test equipment at KSC. Some equipment was approved for one time use while 
other equipment was determined to require complete Failure Mode & Effects Analysis including 
the identification of Critical Items. In 2001, Space Station Program Manager created a new 
Level 2 Support Equipment Control Board at KSC to provide a program level forum to address 
recurring issues with support equipment 70 . 

Despite the long and varied history of the management and development of ground systems 
supporting ISS, there are several examples of commonality between Level 3 projects and in one 
case, between programs. In the early 1990s, KSC did conduct commonality assessments prior to 
the start of any new support equipment designs. The assessment had to demonstrate that 
Spacelab, Shuttle and other programs were researched and no equal or similar equipment existed 
to perform the ground operations task. Lists for each Work Package were refined to limit 
duplication and to assign responsibility for the development of each piece of GSE. In most 
cases, support equipment required for a particular element was developed by the element 
contractor. KSC developed and provided most common equipment that was used to process 
multiple ISS elements. Examples of mechanical systems include the Cargo Element Lifting 
Assembly (CELA), Cargo Element Work Stands (CEWS) and Removable Overhead Access 
Platform (ROAP). The CEWS was re-used from the Spacelab Program. Agreements to apply 
commonality principles for these systems were established prior to the transition from Freedom 
to ISS. 


Note: The Spacelab Program was conceived in the early 1970s as a means to extend the 
capability to perform science onboard the Space Shuttle, NASA conducted 25 missions with 
Spacelab components in the 1980s and 1990s. Spacelab components were designed and built by 
the European Space Agency. [NASA] 
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Examples of common command, control and communication systems include: 

• Test Control and Monitoring System: TCMS is used to verify the compatibility of Space 
Station interfaces at KSC prior to launch primarily in support of utilization and re-supply 
and return operations. 

• Communication and Tracking Check-out System: The C&TCS primarily verifies the 
functional interface compatibility of International Space Station (ISS) experiments and 
racks with the flight Communications and Tracking System (C&TS). 

• Command and Data Handling System: The C&DH System primarily verifies the 
functional interface compatibility of ISS experiments and racks with the flight Command 
and Data Handling System (C&DH). 

MSFC developed the Element Rotation Stands (ERS) to support several ISS elements including 
the MPLM's, Nodes, and US Laboratory Module. ISS Node 1 with a Pressurized Mating 
Adapter is shown below in an Element Rotation Stand. 



Figure 59: Node 1 in Element Rotation Stand in the SSPF [NASA) 

Commonality with avionics subsystems on board flight elements enabled commonality with 
ground test equipment and operating procedures. The Multiplexer/De-multiplexers (MDMs) all 
used the same processor with different complement of I/O cards. This allowed standardized 
procedures for software loads and test execution for use during stand-alone element testing and 
MEITs. 
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Many subsystems and most experiments contained within the pressurized interior of Space 
Station Elements are mounted in racks based on a common design. Some of the racks were pre- 
installed at the factory while many others were installed at KSC as part of element processing. 
New experiment racks or racks containing Orbit Replaceable Units are carried to and from the 
Space Station via MPLMs. One example where commonality was not achieved was with Rack 
Insertion Devices used at the factory and KSC. The Rack Insertion Device (RID) used at KSC 
was designed for long term use and supported loads of over 2000 pounds. Alternate Rack 
Insertion Devices were developed for use at the factory for the US Lab Module, European 
Columbus Lab Module and the Japanese Experiment Module. The RIDs developed for use in 
the factory were smaller and much lighter that KSC design. Attempts were made to utilize a 
single design. However, it was determined that functional requirements between the various 
elements were not compatible and multiple RIDs were built. The KSC designed RID is shown 
below in Figure 60. 



Figure 60: Preparing to install Racks with the KSC RID [NASA] 

The early processes established during the Freedom phase of the Space Station Program 
presented opportunities achieve commonality on a program-wide basis. As the Program evolved 
in the early 1990s, lack of program manager support limited the ability to achieve greater degrees 
of commonality of ground systems with tangible consequences following decisions to complete 
final manufacturing and assembly at KSC and to perform MEITs. However, commonality was 
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achieved in many cases with both mechanical and data systems. The following table summarizes 
commonalty findings for ground systems developed for the Space Station Program. 

Table 6: ISS Ground Systems Commonality Summary 


ISS Ground Systems Commonality Summary 

Management and Planning 

Program Wide 
Policy 

Yes* 

The Program Commonality Plan clearly documented processes required to 
be followed by all program elements. *However, divergence was observed 
in the early 1990s following the change in program managers. Following 
the transition to ISS, policies established during the Freedom program 
were not continued at the program level. 

Project Wide 
Policy 

Yes* 

♦Since a program wide policy was in effect, project level commonality was 
by default required. However, no level 3 project policy documents were 
located. Personnel designing ground systems had to prove that no other 
systems existed either within the program and external to the program. 
Even after the transition from Freedom to ISS, attempts a achieving certain 
levels of commonality continued and were successful to some degree. 

Timing 

Program 

Formulation 

Commonality Plans were established during concept developing in the 
mid-1980s. As stated above, divergence did occur during the transition 
from Freedom to ISS. 

Contracts 

Yes* 

Early Work Package Contracts were required to follow the Commonality 
Plan. However, following the transition from Freedom to ISS, willingness 
to apply commonality between elements and KSC diminished with certain 
contractors. 

Organization 

Promoted 

Organizational structure of the ground systems development organization 
at KSC did not negatively impact the application of commonality. 

Levels of Commonality 

Between Programs 

Yes 

Cargo Element Work Stands were re-used from the Spacelab Program and 
the O&C high bay was used to support final manufacturing and assembly 
of several Truss Elements. 

Between Projects 

Yes 

Several examples of commonality between projects (Station Elements) 
were observed at KSC with both mechanical and data systems. 

Between Elements 
within Ground 
Operations Project 

Not Applicable 

Ground systems supporting Space Station processing were considered 
essentially one ‘element’. 

Between 

Subsystems within 
Ground System 
Elements 

Indeterminate 

It is likely this level of commonality did exist. However, analysis of 
specific designs was not performed to determine this for Space Station 
ground systems. 

Types of Commonality 

Operations 

Yes 

Examples include avionics software load and check-out procedures and 
mechanical operations such as Element lifts and rotations. 

Technology 

Yes 

Avionics ground test equipment in some cases consisted of same 
processor and I/O boards used on flight hardware. 

Design 

Indeterminate 

It is likely this type of commonality did exist. However, analysis of 
specific designs was not performed to determine this for Space Station 
ground^stems^ 
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5.4 Constellation Program 

Full scale development of both flight and ground systems to support the Initial Phase of the 
Constellation Program is underway. The ‘Initial Phase’ of the Constellation Program consists of 
development of the Orion Crew Exploration Vehicle, Ares I Crew Launch Vehicle and Ground 
Systems to support crew transport to and from the International Space Station. The ‘Lunar 
Phase’ of the program will consist if the development of the Ares V Cargo Launch Vehicle, 

Altair Lunar Lander and Lunar Surface Systems to support human missions to the lunar surface 
no later than 2020. NASA and contractor teams at all ten NASA centers are supporting the effort 
to develop the Ares I Crew Launch Vehicle, Orion Crew Exploration Vehicle as well as ground 
systems at the Kennedy Space Center as shown below in Figure 61 : 
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Figure 61: Constellation Work Distribution [NASA] 


Constellation Program Management is based at the Johnson Space Center in Houston Texas and 
is commonalty referred to as ‘Level 2’. Orion, Ares, Mission Operations and Ground Operations 
Projects are referred to as ‘Level 3’ and are described below in Table 7. 


- 106 - 





Table 7: Constellation Level 3 Project Summary 


Constellation Program 

Project Name 

Lead Center 

Primary Responsibilities 

Orion Project 

JSC 

Development of the Crew Exploration Vehicle (CEV) System 

Ares Projects 

MSFC 

Development of Crew Launch Vehicle (Ares I) and Cargo 
Launch Vehicle (Ares V) Systems 

Ground Operations Project 

KSC 

Development of operations concepts and Ground System to 
support spacecraft and launch vehicle processing at KSC; 
infusing operability into the design of the spacecraft and launch 
vehicle systems during design; and planning for ground 
i operations. 

Mission Operations 
Project 

JSC 

Overall mission planning and execution. Oversees the 
transition of existing mission operations, planning and training 
systems such as control centers currently supporting Shuttle 
and ISS to support Constellation. 

EVA Systems Project 

JSC 

Development of all space suit related hardware systems in 
support of Launch, Entry, Abort and Extravehicular Activities 
(EVA) 

Altair Project 

JSC 

Development of the Lunar Lander System including both 
crewed and cargo variants 

Lunar Surface Systems 
Project 

JSC 

' Development of flight hardware systems to support the buildup 
of a lunar outpost and exploration of the lunar surface. 
Hardware elements under consideration include crew habitat; 
pressurized logistics modules; surface mobility systems; insitu 
resource utilization systems and surface power systems. 


In addition to the NASA centers shown in Figure 61, contracts were awarded to several well 
known aerospace companies: 

• Lockheed Martin: Orion Crew Exploration Vehicle 

• Boeing: Ares I Upper Stage and Ares I Instrument Unit 

• ATK: Ares I First Stage 

Development for ground systems at KSC are led by NASA design teams augmented with support 
contractors. In most cases, modification and fabrication of new hardware are competitively 
awarded for discrete systems such as the Mobile Launcher and Pad Lightning Protection System. 
Single or multiple contracts will also be awarded to support the ground processing and launch 
operations in 20 1 0 or 20 1 1 . 

As indicated by Figure 61, Table 7 and the number of major contactors awarded, integration 
within the Constellation Program will be a complex task. The NASA Constellation Level 2 
systems engineering team developed a number of programmatic documents to ensure technical 
integration across the Level 3 projects. The Constellation Commonality Plan was released in 
early 2008. Several types of commonality were defined including Identical; Interchangeable; 
Modular; Interoperable and Interchangeable. Several levels of commonality were identified as 
well including Commonality within systems and elements; Commonality between systems and 
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elements; Commonality within subsystems, assemblies and subassemblies; Commonality 
between subsystems, assemblies and subassemblies; Use of standard parts (EEE) and 
Commonality relative to the Software Support Environment (SSE). 

The primary goals described in the plan are to lower mass by reducing the number of different 
spares and to potentially increase reliability. The commonality plan defines roles and 
responsibilities between Level 2 and Level 3 and includes provisions for periodic monitoring at 
Level 2 systems engineering control boards and at key program milestones including PDR and 
CDR. Data bases will be maintained to allow designers to search for existing parts/systems using 
the Commonality Assessment Tool (CAST). The Constellation Program also maintains a list of 
standard Electrical, Electronic, and Electromechanical parts to be used by the flight hardware 
projects. It also should be noted that the Constellation Architecture Requirements Document 
references commonality in several areas. 

The Commonality Plan was developed to address commonality within flight hardware systems 
and specifically excludes ground systems and facilities. Therefore, commonality within ground 
systems is encouraged though not specifically required or monitored by Level 2. However, the 
Ground Operations Project, Orion and Ares are all collaborating closely to avoid development of 
duplicate ground systems. Working groups were established between the Ground Operations 
Project and flight hardware projects to identify and establish accountability for all GSE and SE 
expected to be used at KSC. Categories of this equipment include transportation and handling 
equipment, access kits, covers, commodity servicing equipment, electronic GSE, landing and 
recovering GSE, etc. Several thousand items are expected to be identified. 

As discussed earlier in this chapter, problems with the development of GSE in Apollo and other 
spaceflight programs led to the development of GSE design standards. The problems were 
recognized by multiple NASA centers and some centers including KSC, developed their own 
standards (DE-5 12). As part of an effort to reduce conflicting standards, the Office of the Chief 
Engineer at NASA headquarters issued an agency wide GSE Standard in the mid-1990s: NASA- 
STD-5005 Standard for the Design and Fabrication of Ground Support Equipment 71 . Rev C of 
the document is under review and will be released this year. Thus, an important enabler for 
commonality between projects for ground systems is in place for the Constellation Program. 

In 2006, KSC reorganized and created a center wide engineering organization. As shown in 
Figure 62, the structure of the new organization was based on discipline. 
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Figure 62: KSC Engineering Directorate [NASA] 

As discussed in chapter two, Constellation ground systems at KSC are composed of Level 4 
Elements and Level 5 subsystems. Subsystems frequently span multiple elements. In order to 
ensure design consistency for subsystem across elements, engineering personnel with the same 
discipline develop level 5 subsystems. Design reviews are conducted vertically for each element 
at level 4 and horizontally for each subsystem at level 5. 



Figure 63: Level V Subsystem Integration across Ground System Elements [NASA] 
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A good example this is approach is the design and development of the four Ares I Mobile 
Launcher Tilt-up Umbilical Arms shown in Figure 64. 



Figure 64: Tilt-up Umbilicals [NASA] 


Each Umbilical requires expertise in areas such as electrical power, pneumatics, cryogenics, 
structures, mechanisms and environmental control systems. Engineers from each discipline are 
matrixed to each Tilt-up umbilical design team while retaining strong ties to the home 
engineering organization. A Lead Design Engineer (LDE) is assigned to each umbilical to 
oversee the development of each Umbilical. A ‘Super Lead Design Engineer’ oversees the 
development of all four umbilicals. The umbilical design team structure is shown below in 
Figure 65 (note: not all engineering disciplines are shown). 
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Figure 65: Tilt-Up Umbilical Design Team Structure 

The Super LDE is responsible for ensuring commonality in design and in component selection 
across all four umbilicals. While there is no specific commonality plan in place for the Ground 
Operations project, the extensive experience base present in both design and operation 
organizations at KSC recognize the value common design and parts. The use of standard parts, 
common designs and compliance with well known standards is accepted as standard practice at 
KSC. 

Tests in support of development of the Ares I Upper Stage propulsion system will be performed 
with a Main Propulsion Test Article (MPT) in modified test stands at the MSFC beginning 
sometime in Fiscal Year (FY) 2011. The manufacturing and assembly of the Upper Stage will 
occur at NASA’s Michoud Assembly Facility in Mississippi. Prior to transportation to KSC, 
Upper Stage acceptance tests will be performed at SSC. The Acceptance Tests, also referred to 
as ‘Green Runs’, are planned for each Upper Stage for the first several test flights and 
operational missions. As part of Ares I Upper Stage test planning, the Common Propellant 
Distribution System (CPDS) development team was formed to explore the potential for 
commonality between ground systems at KSC, MSFC and SSC. Anticipated commonality 
benefits were reduced life cycle costs and early operation test experience for systems planned for 
use at KSC - ‘Test as fly, Fly as you test’. 

The team consisted of representatives from MSFC, KSC, SSC and GRC. Sub-teams were 
formed from engineering disciplines including mechanical and fluids; command and control; and 
purge, vent and drain; and GSE. Systems engineering and project support sub teams included 
safety and mission assurance; requirements; risk management, configuration management and 
CAD modeling. 

The CPDS team formed in spring 2007 and immediately began developing a candidate list of 
GSE for use at all three test sites: 

• LH2 Tank Relief/Vent Valve Actuation Panel 

• LH2 Fill & Drain Skid with associated pneumatic support panels 
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• LH2 Vehicle Fill & Drain Valve Actuation Panel 

• LH2 Pre-Press Panel (Helium supply only) 

• L02 Tank Relief/Vent Valve Actuation Panel 

• L02 Fill & Drain Skid with associated pneumatic support panels 

• L02 Vehicle Fill & Drain Valve Actuation Panel 

• L02 Pre-Press Panel (Helium supply only) 

• CGHe Bottle Fill Panel (Helium supply only) 


The simplified drawing of the common GSE considered for CPDS is shown below in Figure 66. 
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Figure 66: CPDS GSE [NASA] 

Key ground rules and assumptions were established early including: 

• Systems shall be designed to KSC specifications and standards per NASA-STD-5005 and 
the KSC launch pad environment. 

• Fluid systems design will follow KSC launch operations design for all performance 
critical function systems. 

Detailed planning and trade studies continued into late 2007. Budget estimates were produced 
for different levels of common GSE ranging from 50% to 100% for the three test sets. However, 
while KSC planned to procure entirely new GSE to support Upper Stage fueling operations 
during launch countdown, SSC planned to leverage offlegacy systems during the development 
of initial project budgets in 2006 and 2007. Thus, in order to achieve some levels of 
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commonality, the program would have to provide additional funds to SSC and MSFC. Total 
costs for 100% commonality were estimated to be over $15M. Constellation Program budgets 
for FY2008-FY2010 are constrained. Ultimately, the CPDS team had to settle on an approach 
that relied on GSE manufactured with available components at SSC and MSFC that did not 
require additional funds. The procurement of any new parts determined to be critical to test 
operations will be identical to those in use at KSC. Thus, a certain degree of component 
commonality will be achieved. However, many of the operation benefits rely on early test of an 
integrated system common to KSC. Therefore, the operational benefits to KSC likely are 
significantly reduced. 

The use of common control and data acquisition systems for Upper Stage test and operations at 
all three centers was also briefly investigated. As with the propellant GSE, existing legacy 
systems were already planned for use at MSFC and SSC while KSC planned to develop new 
systems. Operators at SSC preferred to maintain commonality between SSC’s own test stands 
using the legacy systems. They expressed concerns over costs and the technical risk of replacing 
existing control systems in other test stands to maintain commonality within SSC. It was also 
noted that KSC’s redundancy requirements would likely reduce response times at SSC violating 
high speed response time and data recording requirements. MSFC also objected to the 
commonality proposal for similar reasons. The project need dates for various levels of 
capabilities within each project were not in alignment further complicating commonality 
between the three centers. 

The Constellation Program is currently investigating the application of commonality across 
projects in command, control and communication systems. Preliminary studies were conducted 
in 2006 to determine the feasibility of using the same or similar systems in control centers at JSC 
and KSC. A trade tree was constructed as shown in Figure 67 to assess various control center 
architectures as well as commonality. 
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Figure 67: Launch Control System - Mission Control System Trade Tree [NASA] 

Various levels of commonality were assessed for risk and benefit as shown in Figure 68. 


Potential 

Benefit 
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Low 


Low 
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► Builds and broadens agency 
intellectual capital in creating 
common software solutions 


► Potential savings very likely, but 
reduced significantly relative to 
common architecture approach 

► Incremental approach toward 
common systems in lower risk 
areas only 

► Compatible with current system 
planning concepts 


► No additional benefits 


Figure 68: Early Control Center Commonality Risk Benefit Summary [NASA] 

The study found that increasing the level of commonality increases risk in terms organizational 
dependencies. These and other early studies resulted in the formation of the Command, Control 
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and Communication Team (C3I) that now includes members from most NASA centers. The C3I 
vision statement is as follows: 


“To ensure that Constellation Systems can be controlled safely, reliably, affordably, and 
robustly while planning for evolvability, interoperability, commonality, and sustainability 
by using standards, architectural constructs (layers, components, etc.) and an end-to-end 
engineering approach. ” 


Significant progress was made during the last year on developing C3I specifications to enable 
interoperability across the Constellation Program. C3I specifications apply to communications 
between Level 3 projects. Intra-communication within Level 3 projects is not required to follow 
C3I specifications. 


While commonality is a goal for Constellation Command, Control and Communication Systems, 
it is not a requirement. However, commonality studies between Orion factory control systems 
and KSC Launch Control Systems are underway. The number and complexity of subsystems 
required to be monitored by the Launch Control System is dominated by the Ares I Upper Stage 
as shown in Figure 69. 
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Figure 69: Launch Control System Subsystem Control and Monitoring [NASA] 


The number of systems to be monitored by the Orion Factory Control System is far less than the 
combined Ares, Orion and Ground Systems that will be monitored by the Ground Operations 
Launch Control System (Chapter 2). Furthermore, the level of required redundancy and other 
safety considerations for critical launch operations is greater than requirements in the factory 
environment. Thus, there are considerable differences between the operating environments for 
the two systems further complicating the commonality trade study. 

As stated in Chapter 2, the Shuttle Launch Complex 39 will be modified to support Ares I and 
Ares V launch operations. However, in 2006 a study was conducted to assess the feasibility and 
benefits of using Launch Complex 40 (Titan) for Ares I/Orion. Operations concepts and high 
level ground system architecture were developed to perform a technical risk and cost assessment. 
While using Complex 40 was determined to be technically feasible, the study indicated that near 
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term DDTE costs far exceeded DDTE costs for Complex 39 as shown in Figure 70. Relative 
costs are shown on the vertical axis. The vertical axis starts at 0. 



FY10 


□ LC39 

□ LC40 


Fiscal Year 


FY11 


Figure 70: LC-39/LC-40 DDTE Cost Comparison [NASA] 


Figure 70 illustrates the magnitude of funding required for substantial modifications to an 
existing Pad not originally designed for vehicles the size of Ares I. Primary cost drivers were the 
need to replace virtually every LC-40 ground system, modify the flame bucket, build a new 
vertical integration facility, build new transporters, etc. The cost to develop a new Pad would be 
much greater. In this case, cost was the dominant factor enabling commonality between Shuttle 
Program and Constellation and for ground systems supporting Ares I and Ares V. 

As shown by the LC-39/LC-40 study, substantial cost savings are being realized early in 
program through the high level of reuse between the Shuttle and Constellation Programs. 
Commonality between the Shuttle and Constellation programs is being achieved primarily with 
facilities, structures, large mechanical systems and large fluid systems. The Shuttle Launch 
Processing Systems will be replaced with the new Launch Control Systems. However, modem 
programmable logic designs in use to monitor and control ground systems at the Pads today will 
be re-used in Constellation. Reuse between Shuttle and Constellation Program is shown in Table 


8 . 
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Table 8: Shuttle to Constellation Ground Systems Re-use 


Shuttle to Constellation Ground Systems Re-use 


Ground System 

Comments 

Industrial Area Institutional Support 
Facilities and Infrastructure 

Headquarters Building, Central Instrumentation Facility, 
Occupational Health Facility, Training Auditorium, warehouses 
and numerous other smaller facilities were all reused. Supporting 
infrastructure such as roads, railways, sea ports, power distribution 
systems, water systems, etc were also reused. 

Operations and Check-out Building 
Astronaut Crew Quarters and High Bay 

O&C High Bay is in the process of being completely gutted and 
refurbished to support Orion final manufacturing and assembly. 
Astronaut Crew Quarters will be used for Constellation. 

Hypergolic Maintenance Facility 

Will not be required for Constellation 

Vehicle Assembly Building 

High Bays 1-3 will support Ares 1 /Orion and Ares V/Altair vehicle 
stacking and integration. 

Mobile Launch Platforms (MLP) 

One MLP will be used to support the Ares I-X Test Flight in April 
2009 (one time use only). A new Mobile Launcher will be 
constructed for Ares I (Shuttle manifest would not support early 
turnover of a Shuttle MLP for re-use). One Shuttle Mobile Launch 
Platform will be used for Ares V. 

Crawler-T ransporter 

At least one Crawler Transporter will be reused. A new Crawler 
Transporter may be required for depending on Ares V 
configuration (roll-out weight). 

Crawler Way 

Tests are underway to determine whether or not upgrades are 
required. 

Launch Control Center (LCC) 

All LPS equipment will be removed from the firing rooms. LCC 
Firing Room one was decommissioned in 2007 and LCS 
equipment is being installed to support Ares I-X. Only two of four 
Firing Rooms are planned to be used for Constellation. 

Launch Pads 39A and 39B 

Pad B will be used to support Ares I/Orion Launch Operations and 
Pad B will be used to support Ares V/Altair Launch Operations. 

Orbiter Processing Facilities 

Will not be required for Constellation 

Assembly and Refurbishment Facility 

Will be used to support SRB refurbishment for Ares I and Ares V 

Rotation, Processing and Surge Facility 

Will be used to support SRB stand-alone operations for Ares I and 
Ares V 


The Commonality summary for the Constellation Program is shown in Table 9 on the following 
page. 


- 117 - 


Table 9: Constellation Ground Systems Commonality Summary 


Constellation Ground Systems Commonality Summary 

Management and Planning 

Program Wide 
Policy 

No 

CxP 70132 was developed address commonality within flight hardware 
systems and specifically excludes ground systems and facilities. Therefore, 
the Commonality within ground systems is encouraged though not 
specifically required or monitored by Level 2. However, the Ground 
Operations Project, Orion and Ares are all collaborating closely to ensure 
duplicate ground systems are not developed and that ground systems 
developed by flight hardware provides for use at KSC are designed in 
accordance with Agency level GSE design standards. 

Project Wide 
Policy 

No 

No commonality plans exists for the ground operations project. However, 
program and project management strongly encourages projects to seek 
common design solutions for both flight and ground systems as evident by 
the studies directed to examine commonality. During design of Level 5 
subsystems, lead design engineers verify commonality of design and 
components. 

Timing 

Project 

Design 

CxP 70132 was after SRR for Ares, Orion and Ground Operations. 

Contracts 

Yes* 

Flight Hardware contractors are required to develop ground systems to 
STD-5005B. However, contracts were awarded prior to the release of the 
Commonality Plan. 

Organization 

Promotes 

Structure of the ground systems design organization at KSC promotes 
commonality of design and component selections for Level 5 subsystems. 

Levels of Commonality 

Between 

Programs 

Yes 

Significant re-use between Shuttle and Constellation Program as described 
in Table 8. 

Between Projects 

Yes 

Ground Operations Project, Orion and Ares are all collaborating closely to 
avoid development of duplicate ground systems. Working groups were 
established between the Ground Operations Project and flight hardware 
projects to identify and establish accountability for all GSE, FSE and SE 
expected to be used at KSC. 

Between 
Elements within 
Ground 
Operations 
Project 

Yes 

Level V subsystems are designed ‘end-to-end’ across multiple elements. 
Therefore, commonality of design and components exists between 
elements. 

Between 
Subsystems 
within Ground 
System Elements 

Indetermi 

nate 

Subsystem designs are not sufficiently complete to make this 
determination. However, this level of commonality is likely for subsystems 
within the Command and Control Element. 

Types of Commonality 

Operations 

Yes 

Shuttle payload processing. Similar operational procedures are used to 
test and check-out payloads prior to installation in Orbiter payload bay. 

Technology 

Yes 

Establishment of common components for Level 5 subsystems including 
electrical and fluid systems components for use in multiple ground 
systems. 

Design 

Yes 

Tilt-up Umbilical Arms are good examples of design commonality. 
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5.5 Special Topic: Commonality within Facilities and Facility Systems 

A complete discussion regarding commonality at the launch site includes facilities. The 
development and modification of facilities and facility systems equipment at KSC represents an 
important and substantial part of preparing the launch site for new programs. Minimizing life 
cycle costs for operating and maintaining facilities and facility systems is driven in part to the 
variability and reliability of facility systems equipment. Over the years, facility design engineers 
at KSC standardized on power meters, protective relays, programmable logic controllers, fire 
alarm control panels, lift stations and interfaces to Kennedy Complex Control Set (controls air 
conditioning, power, etc across the entire center). Project Managers have standard design 
checklists and templates for design projects to ensure standard parts and designs are used. This 
also ensures designers address all Federal, State, NASA and KSC regulations, policies, 
standards, best practices and lesson learned. All 60% and completed design packages for 
Constellation are reviewed by the managers and leads. 
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6 Summary and Forward Work 


The application of commonality in ground systems used for launch operations emerged 
following multiple problems cited during development and operation GSE to support launch 
vehicle and spacecraft ground operations during the Apollo program. The ACE system was the 
best example of commonality applied across projects and between the operational and 
manufacturing environment. However, ground operations personnel at KSC were faced with 
GSE that did not work and was difficult to maintain and operate. Underlying causes for these 
problems were traced to a lack of design standards for equipment designed to accommodate the 
unique environment of KSC, organizational issues with GSE development teams and the lack of 
a establishing a deliberate program policy early in the program to apply commonality with GSE 
developed by multiple flight hardware projects. To put it more simply, the NASA/contractor 
teams of the 1960s were young and relatively inexperienced. At the time, Apollo was the most 
complex development program both in terms of new technology requirements and the integration 
required to manage the large and varied NASA/contractor teams. 

Beginning with the Space Task Group of 1969, the value of commonality was recognized at the 
earliest phases of the Space Shuttle Program as part of the goal to significantly reduce both 
development and operational costs of space flight. KSC Center Director Debus specifically 
applied the Space Task Group’s call for commonality during the initial ground systems concept 
development. Leveraging off the lesson’s learned from Apollo, KSC developed design standards 
for ground support equipment, support equipment, facilities and facilities systems. Development 
organizations were organized by engineering discipline and matrixed to project organizations 
developing ground systems. The new standards enabled commonality of systems required at 
both the factory and launch site without the need for costly redesigns. New organizational 
structures based on discipline ensured commonality of ground systems designs in use across the 
space center such as fluid and gas systems, command and control systems and mechanical 
systems. Commonality of systems used to fuel the Space Shuttle for launch operations and the 
main propulsion test stands at SSC were excellent examples of reducing overall GSE 
development costs between the two development centers. It also provided an opportunity to test 
GSE, complex software algorithms and operational procedures prior to the arrival of the flight 
hardware at KSC. 

The Space Station Commonalty Program (SSCP) was the clearest and most comprehensive effort 
to achieve commonality of the four programs studied for this paper. The SSCP established 
accountability; authority; policy; processes; and tools for commonality that applied to both flight 
and ground systems across the program. A Level 2 Program GSE Management Office was 
established at KSC to over see the development of all GSE across the program. The SSCP was 
established during formulation prior to the detailed design and applied to the contractors building 
the flight hardware. All the ‘ingredients’ required for a successful commonalty effort were in 
place early in the program. Commonality agreements were made with the development of 
several mechanical systems including the Cargo Element Lifting Assembly, Cargo Element 
Work Stands and Removable Overhead Access Platform and were later used to support multiple 
elements. However, leadership changes in the Space Station Program in the late 1980s illustrate 
the effects of limited support for commonality by program management. Almost overnight, 
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commonality was de-emphasized. In fact, many of the lessons learned from the Apollo Program 
that were applied during the Shuttle Program were abandoned in and effort to control growing 
costs of the program. Driven by the ‘ship and shoot’ philosophy, expectations for the design and 
development of factory test equipment and GSE were marginalized by limited application of 
ground system design standards. The Level 2 GSE office at KSC was abolished and flight 
hardware contractors were given freedom to develop factory test equipment to their own 
standards. Commonality was essentially a voluntary activity to be managed by Level 3 Projects 
with little to no oversight by Level 2. 

Following the transition from Freedom to ISS in 1993 and in an effort to overcome schedule 
delays with the manufacturing of flight hardware, several station elements were shipped to KSC 
with significant travelled work (incomplete factory assembly). Problems appeared immediately 
with factory test equipment and GSE including fluid servicing equipment, ground power 
supplies, load banks and simulators. Eventually, the Space Station Program Manager re- 
established Level 2 Support Equipment Control Board at KSC to provide a program level forum 
to address recurring issues with support equipment. 

While the Constellation Program did establish a commonality plan at the program level, 
compliance for ground systems development is voluntary. However, program and project 
management strongly encourages projects to seek common design solutions for both flight and 
ground systems. Constellation program and project management clearly support requirements 
for ground system design standards and the C3I initiatives. They have directed studies to 
examine commonality in command and control systems and many other areas within 
Constellation. Tools provided at the program level are available to be used for ground systems 
commonality assessments. The extensive experience base present in both design and operation 
organizations at KSC recognize the value common designs and components. At KSC, 
commonality is facilitated by the structure of the design organizations responsible for the ‘end to 
end’ subsystem design at Level 5. The use of common parts, common designs and compliance 
with well known standards is accepted as standard practice at KSC and other NASA centers 
responsible for the development of ground systems. The cost of replacing center infrastructure 
and major ground systems such as the VAB, Launch Pads, Mobile Launch Platforms and LCC 
for Constellation would likely cost a billion dollars or more. As with the Apollo to Shuttle 
Transition, the applying commonality between to the Shuttle and Constellation Programs yielded 
substantial cost savings. 

A summary of key factors for ground system commonality is shown below in Table 10. 
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Table 10: Key Factors for Ground System Commonality 


Factor 

Comments 

1 ) Leadership 

• Compliance with commonality initiatives is highly dependent on program 
manager support. 

2) Timing 

• Early deployment of policy and processes is critical to avoid arguments 
against commonality due to rework costs later in the design cycle and costly 
modifications to contracts awarded before commonality policy is established. 

• Opportunities for commonality should be identify during architecture 
development and continue through system decomposition with the goal to 
identify common systems and subsystems as early as possible 

• Understand relevant operations concepts early to develop requirements that 
support all operating environments planned for common systems/sub-systems, 
o Small differences in operating environments can lead to significant 

variability in architecture, requirements and implementation. 

3) Standards 

• Ensures compatibility with launch site environments 

4) Organization 

• Design Organization facilitates commonality across elements developed 
within a single implementation organization. 

• Strong Systems Engineering and Integration at Level 2 enables commonality 
approach to be optimized for overall program performance. 

• Once a common system or subsystem is identified, accountability should be 
assigned early to a single design organization to avoid the natural tendencies 
to propose and develop competing solutions. [This is not to imply a limitation 
on stake holder involvement for all applications.] 

5) Policy, 
Processes 
and Tools 

• Provides necessary rigor required to enforce, monitor and measure 
commonality effort 

• Tools provide a standard means assess commonality consistently across 
projects 

6) Contracts 

• Must include requirements to comply with commonality processes 

• Contractors should be incentivized to identify commonality opportunities and 
support program wide commonality initiatives 

7) Flight 
Hardware 
Architecture 

• Fewer flight hardware to ground systems interfaces drives ground system to 
flight hardware integration across the entire vehicle stack (integrating 
example of Space Shuttle Orbiter) 

• Proliferation of unique subsystems on the launch vehicle and spacecraft leads 
to proliferation of unique GSE on the ground. 

8) Re-use of 
Legacy 
Systems 

• The most dominate costs savings factor that can be attributed to commonality 
of ground systems. Type of Commonality is re-use. Level of Commonality is 
between programs (re-use of existing ground systems from prior programs 
such as Launch Complex 39, the Vehicle Assembly Building, Mobile Launch 
Platforms, Off-line check-out facilities, etc). 

• In some cases, legacy systems hinder commonality between projects in new 
programs (one project using a legacy system while another project using a 
new design). 
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The primary value of this paper is capturing historical perspectives and identification of key 
factors affecting commonality of ground systems in all four major human space flight programs 
at KSC. The breadth of this paper is wide and specific examples of both successful and 
unsuccessful applications of commonalty are captured for each program. However, many 
questions remain and deeper penetration into existing ground systems may help to quantitatively 
understand the ‘levels’ of ground systems commonality actually achieved at KSC, other centers 
and in factory environments. For example, the Shuttle Program has over 5000 discrete types of 
GSE items at the KSC. It would be interesting to determine how many of these items already 
exhibit or could exhibit some degrees of commonality; what ground system domains (fluids, 
mechanical systems, command and control, power, etc.) are more likely to benefit from 
commonality; and what levels (element, system, subsystem, component). 


A successful strategy for commonality is not without some degree of additional and largely near 
term development costs. Imposing commonality requirements will constrain designs and will 
most likely require far more upfront planning and coordination than traditional methods for 
system development. Additionally, constrained designs may be less likely to be optimized for 
their specific application within an element. This may actually increase costs in certain areas. 
Successful implementation will require both the leadership and development personnel to take a 
holistic view to fully assess the right approach as well as the right level of commonality. 
Consideration must be given both to potential benefits as well as costs prior to mandating 
commonality for large-scale engineering systems. The project manager is faced with the many 
questions: 

• What are the benefits of commonality and how are the benefits measured? 

• To what degree and confidence level can the benefits of commonality be depended up to 
achieve reductions in lifecycle cost during both development and operations? 

• How much should commonality drive the design and development process? 

• What are the costs of imposing commonality? 

• What are the risks of imposing commonality? 

Methods are needed to answer these questions to be able quantify and predict the benefits of 
commonality of ground systems. A key enabler of the successful application of commonality is 
establishing a formal policy during the formulation phase of the program. However, the program 
manager is faced with hundreds of complex policy decisions early in the program that in many 
cases, may limit productivity of the development team. Therefore, each policy decision must be 
made carefully to ensure it is truly value added, provides a positive return on investment and 
directly supports the over all goals of the program. The ability to predict benefits will lead to 
greater management support and lead to a successful commonality program. 
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